GitHub floods cPanel PoCs

cPanel is the control panel behind a huge amount of web hosting. When it breaks, the blast radius is not one app or one company — it is whole fleets of websites. That is why CVE-2026-41940 landed so hard last week. The bug lets an unauthenticated attacker forge a valid session and, in the worst case, walk into WHM as root. cPanel published fixes on April 28, 2026. But the news now is that public GitHub tooling has turned the bug from a dangerous vuln into something much easier to spray across the internet. ### What is the bug, exactly? This is an authentication bypass in cPanel, WHM, and WP Squared. The core issue sits in how cPanel saved and reloaded session data. Bad input could be written into a pre-auth session file, then later interpreted as trusted session attributes. In plain English — the server could be tricked into believing a login had already been validated when it had not. ### Why is that such a big deal? WHM is the admin plane for a hosting server. If an attacker reaches that layer as root, they are not just defacing one site. They can touch accounts, mail, databases, SSL settings, and server configuration. watchTowr’s framing is basically right here — this is the management plane for a meaningful slice of the public internet. ### What changed after disclosure? The gap between disclosure and weaponization was tiny. cPanel disclosed the issue on April 28. R-fx notes that a working public PoC appeared the same day, based on watchTowr’s research. Since then, GitHub has picked up more copies and more operator-friendly wrappers, which is the part defenders hate most — replication lowers skill requirements. ### What is showing up on GitHub? At least two repos make the trend obvious. XsanFlip’s project describes itself as a “high-performance, multi-threaded” auditing tool with dynamic port discovery and batch scanning. kmaruthisrikar’s repo goes further into the exploit chain and lays out the session-forgery steps in detail, including how injected values get promoted into the cached session playbook. ### Why does automation matter so much here? Because exposed cPanel hosts are easy to enumerate, and the protocol is scriptable. A scanner can try common ports like 2082, 2083, 2086, and 2087, test whether the target is vulnerable, and move on fast. Once that logic is wrapped in concurrency, one person can probe a big list cheaply. The catch is that defenders now face volume, not just sophistication. ### Are patches out? Yes — but patching has been messy enough that the advisory kept changing. cPanel updated its article multiple times through May 3, including clarified patched versions and a revised detection script after false positives. Current patched builds include 11.86.0.41, 11.110.0.97, 11.118.0.63, 11.124.0.35, 11.126.0.54, 11.130.0.19, 11.132.0.29, 11.134.0.20, and 11.136.0.5, plus WP Squared 136.1.7. ### So what should operators do first? Patch first. Not “schedule a maintenance window soon” — patch first. Then restart the affected services, rerun the updated detection tooling, and assume internet-exposed hosts were probed already. If you run edge filtering or WAF rules, this is the moment to use them, because of automation and the speed of prior exploitation. ### Bottom line? The story is no longer just “cPanel shipped a critical fix.” It is “the exploit has been packaged for mass use.” Once GitHub fills with scanners, the race changes — and slow patch cycles start to look a lot more expensive.