Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

FreePBX is a web-based GUI for managing the Asterisk VoIP phone system. The application is easily set up on a local network and is built on PHP. The ability to access this would result in the interception/stealing of phone calls, voicemails, etc.

In August 2025, a FreePBX user started getting strange error messages in their access logs. A day later, a user found a file called .clean.sh on their box that was cleaning up after an exploit. This is a serious problem! This clearly indicated a remote code execution vulnerability. The WatchTower team had previously reported a post-auth RCE bug to the developers, who didn't care. This time they did. Why?

This appeared to be an unauthenticated RCE vulnerability. Upon reviewing the vulnerability summary, it had to do with bad input validation. Command injection? SQL injection? Still not sure. But, they had a clue to go off of - the issue was in the Endpoint module. This was a plugin for FreePBX that simplified many aspects of the provisioning and management process.

At first, they were looking for SSRFs because requests made from localhost bypassed authentication, but this did not work. After trying to call various modules with a single quote in the parameter, they were greeted with a nice SQL error! This led to a SQL injection that was obviously quite bad. This was still post auth though.

Out of curiosity for the attacker, they set up a honeypot. After waiting for a little bit, a shiny new backdoor appeared on the system! This was calling /admin/ajax.php without authentication. But how?

FreePBX contains a module/extension system to add to your PBX instance. To do this, the module parameter alongside the command is used for routing. Using reflection logic, it will determine if a class exists via class_exists in PHP. This will attempt to load a custom class from risk, in the case of a local system like this.

In the custom PHP autoloader implementation, the function fpbx_framework_autoloader attempts to load the code. This will do some black magic to find the proper file to execute. In practice, this code allows for the execution of any PHP file with the appropriate part of an install. Specifying the module as FreePBX\\modules\\Endpoint\\install results in the install command to run, for instance.

With the authentication bypass, it's not possible to exploit the SQL injection to gain access to the device! This results in a complete authentication bypass for some modules. In the patch, it was only the SQL injection that was fixed and not the authentication issue. This is a design-level issue that likely requires significant effort to resolve.

In the middle of 2025, Sean Heelan made a post describing the usage of an LLM to find a use-after-free vulnerability in the Linux Kernel that was similar to an existing bug. In the post, Sean explains how the LLM found the bug and the limitations of LLMs on security reviews at the moment.

The goal of the author was to rediscover this vulnerability consistently using LLM tools without prior knowledge of the codebase. They wanted to reach the code without needing to build/compile anything. Luckily for them, CodeQL had just launched a system that could analyze code without the need for building the code. Additionally, they didn't want to use an agenetic framework.

Initially, they used a simple cross-function UAF detector in CodeQL that generated 1700 possible UAFs. With this, they used the tree sitter tool to improve the information as a plugin to CodeQL. Additionally, this allowed for a maximum call depth that limited the findings to 217. They pointed their code at the entire /fs/smb/server/ implementation of the Linux kernel. This is 26.4K lines of code, for context.

With these 217 findings, they came up with a plan. First, triage with a smaller model. This would define the "use" from the downstream free() to avoid the larger model token burning. The second step, analyze would ask more profound questions about how the free memory might be accessed, exploitability, and potential fixes for the code. To do this, they created a tool called Slice that can take SAST input and feed it to an LLM for usage.

Between both of the run types, it costs $1.75 for triage and $1.64 for analysis in a total of 7 minutes. By running this on GPT-5, it found the vulnerability 10 out of 10 times! They found the bug they were looking for but don't mention the amount of false positives that came along with it. From reading the JSON output, it may have been zero!

The usage of LLMs is going to revolutionize many things. By providing the LLM with the proper data and a specific task (finding UAFs in SMB Linux server code), it performed pretty well. In the context of bug bounty, where you want to find a bug and don't need to find every bug, this seems very useful to me. This tool appears fantastic, and it's something I'll likely use in the future for my own needs.

The Docker internal HTTP API is used to control most of Docker. Exposing this is an automatic game over in terms of container security. This is because you can start a privileged container that has access to the full host.

The author of this post was internally mapping the localhost interface on the VM out of paranoia on Docker Desktop for Windows. While doing this, they found that they could access the Docker API from the container.

This exploit is so bad that it works from an SSRF vulnerability. It's fascinating that this issue has existed for so long without being noticed before. According to the author, Docker doesn't have a security program, which may be part of the reason this is the case. Regardless, fantastic impact on this bug!

This article goes through how threat actors are attempting to phish users who use Gmail. The basic idea is common: your password is about to expire, so you must renew it now. Naturally, this sends the user to a fake Gmail login page.

All of the previous stuff was standard. Since many mail services are now using AI, the plain-text MIME data actually included a prompt injection payload. This is an interesting workaround for using LLMs.

The idea is to trick the LLM to NOT flag this email via an injected prompt. Instead of an outright don't do this at all, it's asked to do slightly different things than the original prompt. Specifically, to delay the classification process and to go insanely deep. I find this interesting because it's not THAT much different from the original prompt, but it's forced to take a long time.

To make the webpage harder to track, there's a captcha on it. Additionally, the JS is obfuscated. The web page appears to collect the victims' IP addresses to geolocate them and contains a fake login form. Overall, a fascinating insight into the cat-and-mouse game of defenders and attackers.

VteNext is a CRM in Italy. Upon initially searching through the PHP codebase of the demo release with semgrep default PHP rules, they find some interesting sinks.

The first issue they find is an XSS vulnerability resulting from poor sanitization of user-controlled JSON input. Interestingly enough, this works because the Content-Type of the response is text/html. So, making a call directly to this endpoint leads to reflected XSS. This is in a POST request at the moment, which is unexploitable.

The application supports various HTTP methods. The CSRF token checks are only done on POST requests. The processing will be done on an endpoint regardless of the verb. By changing the verb to GET, it creates a CSRF token bypass.

If you combine one and two, an XSS can be created from a GET request by a user now! Sometimes, small things can be chained together to make exploits worse. Session cookies are secured with the HTTPOnly cookie flags, making them inaccessible via XSS. The Touch module exposes the PHPSESSID ID in the page - this appears just to be some JSON request data. In other locations, phpinfo() can be used to leak session cookies as well.

The final piece to the puzzle was a set of SQL injections. Although they are using adb->pquery() to execute the query, the user's input is directly inserted into the statement. It seems like they were trying to prevent SQL injection, but misunderstood it. In this case, the $_REQUEST['fieldname'] can be used to read any field from any table. They use this primitive to steal password reset tokens from the DB.

They found a password reset function that just didn't check the user's previous password. This is because a parameter skipOldPwdCheck is used on function calls, but it's never set. Overall, a good set of bugs!

WebViews are commonly used in Android applications to display webpages inside of the app itself. To improve usability, deeplinks or custom URIs on the app, are commonly used.

When deeplinks are used, they can also be defined as browsable and exported in the app's manifest. This allows the activity to be interacted with from outside of the app.

Thus, the content being used for these links must be strictly verified. Otherwise, it can lead to phishing threats. If a webview is rendered in the app silently, then a user might trust the login page.

Sitecore Experience Platform is a Content Management System (CMS). There are at least 22K public Sitecore instances, making this a fairly impactful target.

The HTTP handler XamlPageHandlerFactory has had many issues in the past. This works by internally fetching the handler responsible for page generation. Sitecore will generate the page and initialize every component described in the XAML definition. There are several parameters that can control this dispatch - __SOURCE and __PARAMETERS. Any sort of dynamic dispatch has the potential to go wrong and must be reviewed thoroughly.

The gathered handlers iterate over a method and call methodFiltered.Invoke after checking to see if the function is allowed to be called. There are two somewhat similar implementations of this dispatch, but with the type XmlControl as a valid type in the filtering. This second type is only extended by the handler HtmlPage.xaml.xml! Crazily enough, this allows for nesting dispatch calls.

To do this, call XmlControl that passes the whitelist check. Then, create the arbitrary XAML handler and call it. So, what can this WebControl actually call? The best primitive they found was AddToCache - this leads to an arbitrary cache poisoning vulnerability that is super bad.

Using the first primitive effectively turns this into an authentication bypass, since we could poison any page. While going through the codebase, they found the sink Base64ToObject. After some effort, they found a mechanism to trigger this via an HTML editor API—basic sink-to-source analysis.

I enjoyed this cache poisoning issue a lot. This is because finding this primitive through all of the functions took a long time to think through. What's the worst thing that we can reasonably do given the impact we have? Sometimes, the bug is the simple part, and it's the impact that is harder to figure out.

The author of this post is a member of the CTF team Shellphish. His team, a world-renowned one at that, had earned its way to compete in the DEFCON CTF this year. This is the Olympics of hacking and is home to many of the world's best CTF players. They had previously competed in the AIxCC competition, where LLMs attempted to identify bugs in code.

With all of this in mind, they decided to tackle a pwn challenge called ico. This was a small binary but contained over 6K functions, making this a classic reversing challenge. Throughout the event, Blue Water had solved two of the Live CTF challenges (small one-on-one challenges) using agents running in the background. So, Wil decided to spin up some LLM infrastructure to see if it could be solved this way.

They created a Docker container that contained the IDA MCP server and Cursor inside of it. They gave it a prompt of along the lines of "You are a great reverse engineer. Reverse the application and interact with the binary at this port when needed". After running GPT-5 for back and forth for a long time (with A LOT of tool calls), it outputted a script that did not work but had some good insights on the program. The author posts the exact prompts and output throughout the post, which is very nice to see.

The LLM asked them to create a better script with pwntools for interacting with the challenge based on the information for the commands given by the LLM. This helped but there was still no flag. The LLM hadn't updated the decompilation at all. The author made several changes, including to function names, to provide the LLM with more context on how it works.

After going back and forth a few more times with "we need the flag and not the MD5 hash of the flag", the LLM eventually figured out how to extract the flag from the challenge! Even cooler, they asked it to patch the binary and it was able to fix the challenge as well. Pretty neat!

According to the author, this was a perfect storm: a straightforward path to exploitation with no tricks, just reversing, a simple exploit (just 10 bytes required), and the problem was partially reverse-engineered already. They claim this could be used to solve some CTF challenges, but not most of them. In general, the process of "gather knowledge (from IDA) -> formulate hypothesis -> create exploit script -> analyze script output -> apply new findings to IDA" worked pretty well for them.

GitHub Actions permissions are really complicated to think about when secrets come into the mix. If someone makes a PR, do they have access to the secrets? There are different modes of these but it really makes a difference what code is ran on the repository.

In the case of a Java formatter in the typically "safe" pull_request_target, it was checking out the user's PR from the Pull Request. By placing in a malicious pom.xml file, RCE could be gained in the context of the PR. Since the action can have secrets, this is a serious security issue. Using the secrets and ACCESS_TOKEN, it may have been possible to edit the repository itself.

This attack is known as a "Pwn Request". To protect against it, developers should be very wary about externally facing actions on GitHub. Additionally, scope tokens down as much as possible. Good write up!

Instance providers, like GCP and AWS, have a service for getting credentials local to the server. Obviously, getting an SSRF to get this information is horrible for the client. So, some protections have been added to make this harder. One of these is the requirement of the Metadata-Flavor: Google header.

While on a pentest, the author of this post noticed that adding an extra slash to the instance removed the requirement of this header! But why!? Using http://169.254.169.254/computeMetadata<</>>/v1/instance/ with a single extra slash did the trick. Sometimes, fuzzing and trying weird things is the way to go! Our systems are just so complex nowadays that it's hard to understand how they work.