AhnLab Analyzes 100 GitHub Repositories Following PHP Vulnerability Disclosure

GitHub repository creation spikes around PHP vulnerability disclosure

AhnLab searched GitHub for 'php2shell' and analyzed the top 100 repositories as of 1:30 p.m. on October 22, 2026. Forks were excluded. AhnLab assessed each repository's relevance and classified its purpose based on public information such as repository names, descriptions, and topics.

The analysis found that 99 of the 100 repositories contained material related to CVE-2026-109618 and CVE-2026-109619.

Of the 100 repositories analyzed, 96 were created on October 21. Creation peaked at 19 repositories during the hour beginning at 3 p.m. UTC.

According to the report, defensive repositories appeared first, while the number of attack PoC repositories increased over time. The earliest related repositories included a Corelight detection rule repository created on October 18. Among repositories classified as attack PoCs, the earliest was created by dinosn on October 20.

The creation dates suggest that repositories for exploit testing and security response appeared within a short period around disclosure.

However, the analysis covers public repository information. Repository creation dates do not show whether or when actual attacks occurred.

Defensive repositories outnumber attack-related repositories, but receive fewer stars

AhnLab classified the 100 repositories by purpose as defensive, attack-related, or other.

Defensive repositories were the largest group with 46, followed by 36 attack-related repositories and 18 other repositories.

Among the defensive repositories, vulnerability assessment tools were the most common with 23. The analysis also identified 17 mitigation and patching tools and six repositories containing detection rules or indicators of compromise, or IoCs.

The attack-related repositories consisted of 27 PoC and exploit repositories and nine tools for reproducing vulnerable environments. The other category included four repositories providing technical analysis or information, 13 whose purpose could not be determined, and one unrelated repository that only matched the search term.

Star counts showed a different distribution of interest.

GitHub users can star repositories that interest them, so star counts provide one measure of user interest.

The repositories analyzed had 1,394 stars in total. The 36 attack-related repositories received 1,178 stars, or approximately 85 percent of the total. The 27 PoC and exploit repositories alone received 1,158 stars, approximately 83 percent of the total.

By comparison, the 46 defensive repositories received 148 stars, approximately 11 percent of the total.

The PoC repository from ikow received 617 stars, while the PoC repository from eness received 333. Together, the two repositories received 950 stars, approximately 68 percent of all stars in the analysis.

The top five repositories received approximately 81 percent of all stars, indicating that interest was concentrated in just a few repositories.

Meanwhile, 21 of the 27 PoC and exploit repositories had fewer than 10 stars. Across the full dataset, 61 repositories had one star or none.

Star counts do not establish whether exploit code works or whether its implementation is complete.

Python and Shell predominate; more than half of repositories specify no license

AhnLab also analyzed the programming languages and licensing information in the public repositories.

Python was the most common language at 47 repositories, followed by Shell at 24. Python was used mainly for attack PoCs and vulnerability assessment tools, while Shell was used for server configuration changes and temporary mitigation scripts.

Other languages included PHP in five repositories, JavaScript in three, PowerShell, TypeScript, and HTML in two each, and C, Go, Rust, and Zeek in one each. Eleven repositories had no programming language listed.

The results show that tools for exploit testing, vulnerability assessment, detection, and mitigation were published in a range of programming languages for these vulnerabilities.

Of the 100 repositories analyzed, 51 did not specify a license. The MIT license appeared in 37 repositories, NOASSERTION in seven, Apache-2.0 in two, and EUPL-1.2, AGPL-3.0, and BSD-3-Clause in one each.

When public code has no stated license, the permitted scope of use, modification, and redistribution can be unclear. Organizations using such code for security assessments or internal tool development should review the license terms as well as the code's safety.

Most repository descriptions were written in English, but descriptions also appeared in Chinese, French, Russian, Portuguese, Spanish, and Dutch. None were written in Korean.

Twenty-seven repositories had topic tags, and most included CVE-2026-109618 or CVE-2026-109619.

Conflicting PoC claims and duplicate repositories

The report also found conflicting claims about whether the published attack PoCs actually worked.

PoC code is intended to demonstrate a vulnerability or show that it may be exploitable. PoCs support security research, but claims in a repository do not prove that its code implements the described functionality or has been tested.

According to AhnLab's analysis, repositories from dinosn and 3em0 claimed that the PHP vulnerabilities could enable RCE (remote code execution). In contrast, allureluoli stated that it reproduced only internal state corruption rather than RCE, while VKKKV reported an unsuccessful attempt to reproduce the attack.

These conflicting claims mean that repository descriptions alone cannot establish whether a particular PoC can achieve RCE.

Duplicate repository descriptions raise another concern. AhnLab found that the description for AsviS/PHP2Shell was identical to the description for ikow/php2shell-poc.

An identical description alone does not establish that a repository is malicious. However, an attacker could copy the description of a popular repository, alter the underlying code, and redistribute it. Users should therefore verify the repository's source and review its code.

Among the repositories analyzed, 29 had no description and 11 had no identifiable programming language. This lack of information makes it difficult to determine their functionality or purpose without examining the code.

Distributing malware disguised as a PoC for a popular vulnerability is a known tactic. Code that appears immediately after disclosure should not be run without verification.

Security tools that require administrative privileges need careful review

The analysis noted that public tools intended for vulnerability response can themselves create security risks.

Some mitigation scripts claim to apply configuration changes to all PHP installations on a server with a single command.

Some of these scripts run with administrative or root privileges. Code running with administrative privileges can affect PHP settings and other server components.

Running a script from an unknown source, or without checking what it does, could expose the server to compromise.

The analysis also identified the mothproof3512 repository, whose description states that the tool was created using AI and is not guaranteed to work correctly.

A public tool's convenience and claimed functionality do not establish its reliability. Before applying assessment or mitigation scripts to a production server, users should review the commands they run, the privileges they require, and the scope of their configuration changes.

Precautions for using public code

In the report, AhnLab recommended prioritizing official security updates when using public code related to the PHP vulnerabilities and avoiding unverified code in production environments.

First, prioritize official security updates.

Temporary mitigation tools and unofficial patches from public repositories cannot replace official security updates. Organizations should check the PHP version in use and the security fixes provided by the distribution vendor.

Second, review the scope and impact of temporary mitigation measures.

When an immediate update is not feasible, a temporary mitigation setting such as session.upload_progress.enabled = Off may be considered. However, this setting disables file upload progress tracking, so organizations should assess the service impact and confirm which vulnerabilities the setting addresses.

Third, validate detection rules in the target environment before deployment.

Web application firewall rules that detect or block suspicious multipart requests may also affect legitimate file upload requests. Organizations should therefore assess the potential for false positives before deployment.

Organizations should prioritize rules and guidance from trusted sources, such as Corelight's Zeek and Suricata detection rules and NCSC-NL's operational guidance, while validating their effectiveness in their own environments.

Fourth, review the code in public PoCs and assessment tools, then run them in an isolated environment.

A repository name or star count does not establish that its code is trustworthy. Users should verify the source, commit history, and required privileges, then test the code in an environment separated from production.

Before running a script that requires administrative privileges, users should review everything it does and establish a procedure for reversing changes if necessary.

Distinguish the spread of exploit code from actual exploitability

References

AhnLab, 'GitHub php2shell Repository Analysis Report,' October 22, 2026.

PHP official website, https://www.php.net/

Analysis cutoff. 1.30 p.m. on October 22, 2026. The analysis covered the top 100 repositories returned by a GitHub search for 'php2shell,' excluding forks, and used public information such as repository names, descriptions, and topics. It did not directly review or execute individual code and therefore did not verify actual behavior or the likelihood of successful exploitation.