PHP2Shell Exploit Wins a $2,000 Bitcoin Challenge: Critical PHP Vulnerabilities Under the Spotlight

A public proof of concept highlights the risks of memory corruption, information leaks, and remote code execution in vulnerable PHP applications.

A security researcher known online as killa has reportedly won a public Bitcoin hacking challenge by exploiting two critical PHP vulnerabilities, earning a prize pot valued at approximately $2,021.22 at the time of the challenge.

The challenge, hosted on stealmybitcoin.com, required the researcher to reach a test server and execute commands remotely. The winning attempt reportedly took 19.28 hours, and the researcher subsequently published a proof of concept (PoC) on GitHub.

The incident brings renewed attention to a serious class of PHP vulnerabilities known as PHP2Shell, demonstrating how memory-management flaws can potentially lead to remote code execution.

What Happened in the Bitcoin Challenge?

The challenge involved an intentionally vulnerable PHP server containing a wallet-related target. Participants attempted to exploit the server to reach the protected resource.

The prize initially stood at $500 before donations increased the total to more than $2,000.

According to the challenge's account, early attempts failed because the server was serving static files through PHP's command-line mode, which did not trigger the vulnerable code paths. After the environment was changed to execute a proper PHP page, exploitation became possible.

The researcher later released the public proof of concept on GitHub, allowing security professionals to study the technique in a controlled environment.

However, the published report includes important limitations: the exploit was tested against a local lab environment, and the author did not capture the complete successful request against the live challenge server. The recovered key also reportedly did not match the advertised prize address.

These details are important when evaluating the results. A published PoC demonstrates a potential exploitation technique, but it does not independently verify every claim about a live compromise.

Understanding the PHP2Shell Vulnerabilities

The vulnerabilities are identified as CVE-2026–109618 and CVE-2026–109619. Both reportedly carry a CVSS v4.0 score of 9.2, placing them in the critical severity category.

The issues involve memory corruption and the reuse of data between requests handled by shared workers.

1. Memory Corruption During Cleanup

The first vulnerability can corrupt memory during cleanup following an out-of-memory condition.

Memory corruption is dangerous because it can disrupt the assumptions a program makes about the contents and structure of its memory. Depending on the circumstances, an attacker may be able to influence program execution or obtain information that should remain inaccessible.

2. Reuse of Data From Earlier Requests

The second vulnerability allows data left behind by an earlier request in a shared worker to be reused by a subsequent request.

When sensitive or attacker-influenced data remains accessible across requests, it can undermine the isolation expected between separate operations. In certain circumstances, this behavior can contribute to information disclosure or more serious exploitation.

Together, these flaws can provide the building blocks for an attack that progresses from information disclosure to remote code execution.

How the Published Exploit Works

The PoC reportedly combines two memory leaks to obtain information about the process's memory layout.

At a high level, the exploitation process involves three stages:

Stage 1: Obtaining a heap address

The first leak reveals an address associated with the heap, helping the exploit understand where relevant data resides in memory.

Stage 2: Obtaining a PHP code address

The second leak reveals an address associated with PHP code. Combining these addresses can reduce uncertainty about the process's memory layout.

Stage 3: Triggering code execution

Using the recovered information, the exploit attempts to place a forged structure in memory that causes PHP to invoke a system function.

The script reportedly prints a random test marker, the user ID, and a hash associated with the flag program.

The author states that the exploit succeeded in approximately seven out of ten local laboratory runs. This suggests that the technique was not completely reliable, even in the tested environment.

The key takeaway is that information leaks can become significantly more dangerous when combined with memory-corruption vulnerabilities. Individually, a bug may expose limited information; together, multiple weaknesses can create a path toward code execution.

Which PHP Versions Are Affected?

According to the reported advisory, the affected range extends from PHP 5.4 through PHP 8.5.11.

PHP published fixes on October 21, 2026, in the following releases:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Older branches, including PHP 8.1 and earlier, no longer receive official security fixes. Applications running those versions should prioritize migration to a supported PHP release.

Administrators should verify the official PHP security advisories before planning upgrades and confirm that their specific deployment is running a fixed version.

Exploitation Attempts Were Reported Before the Patches

The challenge is not the only reason these vulnerabilities deserve attention.

The report states that Amazon observed exploitation attempts beginning on October 17, 2026, four days before the fixes were released.

Sophos also reportedly blocked attempts to deliver Potassium, a suspected Mirai botnet variant. However, the available reporting did not establish that those attempts resulted in a successful compromise.

This timeline illustrates an important cybersecurity reality: attackers may begin investigating or exploiting vulnerabilities before defenders have deployed patches.

Public proof-of-concept code can further lower the barrier to experimentation, making timely remediation particularly important.

How Organizations Can Protect Their PHP Applications

Organizations running PHP-powered websites and APIs should treat these vulnerabilities as a priority.

1. Upgrade to a Patched Release

The most important step is to update affected PHP installations to an appropriate fixed version. Firewall rules alone cannot repair a vulnerable runtime.

2. Restart PHP Services and Workers

After upgrading, restart the relevant services and verify that the active PHP workers are using the patched build. Old processes, containers, or bundled runtimes may continue running vulnerable versions if they are not updated correctly.

3. Audit All Runtime Environments

Check production servers, staging environments, containers, background workers, and third-party application packages. A server may appear updated while one component continues to use an older PHP runtime.

4. Monitor for Suspicious Activity

Review application, web server, and security logs for unusual requests, unexpected process execution, abnormal worker behavior, and suspicious outbound connections.

5. Retire Unsupported PHP Versions

Unsupported versions are particularly risky because new vulnerabilities may remain unpatched. Plan migrations to supported releases and maintain a regular patch-management process.

6. Validate the Upgrade

Confirm the active runtime version, restart services where required, and test the application after deployment. Security teams should also check whether their hosting provider or container image introduces additional upgrade requirements.

Final Thoughts

The PHP2Shell case highlights how seemingly separate memory-management issues can combine into a serious security risk.

The reported Bitcoin challenge demonstrates the potential impact of chaining information leaks with memory corruption. At the same time, the limitations described in the published PoC reinforce the importance of distinguishing laboratory results from independently verified live exploitation.

For developers and system administrators, the practical lesson is straightforward: keep PHP installations supported, apply security updates promptly, and verify that every active runtime is actually patched.

In cybersecurity, identifying a vulnerability is only the beginning. Reducing the window between disclosure and remediation is what helps prevent an exploitable weakness from becoming a real incident.