May 18, 2026 Security research Shubham Shah , Adam Kues , Patrik Grobshäuser New Age of Collisions: Reading Arbitrary Files Pre-Auth as root in cPanel (CVE-2026-29205) Times Are Changing These last few months have been super weird. We’ve ended up in a situation several times where we have learnt that an exploits life cycle has significantly been reduced due to the introduction of frontier models that are extremely capable at picking apart software that can be obscure in nature, such as cPanel. Towards the end of March we started looking at cPanel as it was one of the targets we spent a significant time on before AI models had advanced so much at source code analysis ( https://www.assetnote.io/resources/research/finding-xss-in-a-million-websites-cpanel-cve-2023-29489/ ) . Our strategy was simple: decompile every binary inside cPanel back to Perl using AI, and then audit the decompiled Perl with frontier models for critical pre-authentication vulnerabilities. By April 4th, we had a fully working chain for authentication bypass with no pre-conditions (now tracked as CVE-2026-41940). Before this authentication bypass chain, we had also discovered a vulnerability that allowed us to read files as the root user, also without authentication. Along the way, we also discovered a pre-auth XSS and CRLF injection in HTTP response headers. These two separate lower risk bugs are not disclosed in this blog. The file read as root really wasn’t as effective or exciting as the authentication bypass vulnerability. It juggled several different components to achieve a successful exploit, and realistically could only be exploited if we knew a valid email address on the cPanel instance and if the instance could accept an email from us. While we discovered both of these vulnerabilities in early April, our research in cPanel continued towards the end of that month until we saw the news about a threat actor exploiting the issue well before our discovery (earliest indicators from Feb 2026). This made us realise that while we had detections in place well before our competitors in the pre-emptive space, a threat actor had knowledge of this exploit chain almost two full months before us, and about two and a half months for the broader industry. That’s a huge gap. Decompiling Back To Perl A key component of our research was the ability to decompile the binaries included in the cPanel distributions back to Perl. cPanel’s core services (cpsrvd, cpdavd, resetpass, and others) are compiled Perl binaries produced with B::C. With some prompting, we were able to use B::Deparse ( https://perldoc.perl.org/B::Deparse ) to decompile cPanel’s binaries back to Perl code. A lot of the decompiled code was not perfect, missing regexes that are critical towards analysis. B::Deparse cannot recover compiled regular expressions from B::C binaries. All regex patterns appeared as empty patterns //u in the decompiled output. For instance, the cpsrvd binary alone had 228 lost regexes, and cpdavd had 18. The actual regex patterns were recovered by extracting string data from the .rodata section of each ELF binary. The patterns are ordered by byte offset in the binary, which corresponds to their order of appearance in the source code. By correlating the offset-ordered patterns with the position of empty //u entries in the deparse output (within each function), the original regexes can be mapped back to their usage sites. It was really important to stitch these recovered regexes back with the original decompiled code, so that when we went through analysis iterations with frontier models, they had the correct understanding of the code and could meaningfully discover vulnerabilities without being stuck on unknowns, or having to reference separate files to work out what the regexes were in play for certain flows. Pre-Auth Arbitrary File Read As Root (cpdavd Path Traversal) The CalDAV daemon (cpdavd) contains a pre-authentication path traversal that allows reading any file on the filesystem as root. The vulnerability exists in the managed attachment GET handler, which serves CalDAV attachment files without requiring authentication. In most typical cPanel deployments, you’ll see that the CalDAV daemon and its handlers are accessible via ports 2079 (http) and 2080 (https). If these ports are not exposed, we have not determined any way of exploiting this issue as Apache’s URL normalization kills the exploit chain when we try to access cpdavd via port 80 and 443. When requests come through to cpdavd, the request URI is checked against the following regex: ^/calendars/([^/]+)/([^/]+)(/.*)? . From this, three groups are extracted: $principal_user – the CalDAV principal (e.g., user@domain.com ) $collection – the calendar/addressbook collection name $attachment_uri_path – the remainder of the path The $attachment_uri_path is then checked against one of two patterns: ^/.+-attachment-(.+)-(.+)$ ^/.+.cpd/attachment-(.+)-(.+)$ If either of these match, the following code path is hit: my $attachment_full_path = $homedir . '/.caldav/' . $principal_user . '/' . $collection . $attachment_uri_path; $attachment_full_path = URI::Escape::uri_unescape($attachment_full_path); if ((-f $attachment_full_path)) { # read and serve file contents - no authentication check } The path traversal works because the regex runs against the raw URI before decoding. At that stage %2F is just three ordinary characters, all of which satisfy [^/]+, so the encoded slash passes validation. URI::Escape::uri_unescape() then decodes it into a real / during path construction, after the structural check is done. Before this codepath is hit, it’s clear that the cPanel developers attempted to perform some defense in depth mechanisms by dropping privileges to the account owner (instead of root), however there is a flaw in this protection that meant that it was not actually working as intended: 'Cpanel::AccessIds::ReducedPrivileges'->new($system_owner); The return value is not assigned to a variable. The ReducedPrivileges module uses Perl’s RAII pattern: the constructor drops privileges, and the destructor (DESTROY) restores them. Because the object is not stored, it is a temporary that is destroyed at the end of the statement. By the time the file read operations execute later in the code, the effective UID has been restored to 0 (root). This means that the file read vulnerability is able to read any file with root privileges, allowing access to any file regardless of ownership or permissions. The Seemingly Impossible Pre-Conditions While the arbitrary file read vulnerability clearly exists, there are some really tough pre-conditions. Specifically, to even hit the regex that handles file reads, we needed either -attachment- or .cpd/attachment- in the path. What this actually means is that we need a folder in the local system that has this string inside of a directory name. Was there any reliable way to create a directory with a name that we controlled on a cPanel host without authentication? We explored so many different avenues, such as creating Mailman lists, or finding some sort of vulnerability in other cPanel code that created directories with an arbitrary name. Most of these turned out to be dead ends with no real viable exploit path without authentication. After a lot of failures, we pivoted to the Dovecot service, which is responsible for accepting incoming emails for cPanel instances. We found that Dovcot actually has an extremely interesting functionality where it creates directories on the local file system in predictable locations when you send an email to any existing cPanel user and use a + alias inside the email. Whatever comes after the plus alias is included inside the directory created on the local system to store emails that are received for that alias. Ultimately, this meant that we could create a directory such as $homedir/mail/{domain}/{localpart}/.x-attachment-1-y/ and use this in order to read arbitrary files as root (by accomplishing the regex constraint). The dovecot directory creation flow can be found below: The attacker sends an email to {localpart}+x-attachment-1-y@{domain} via any SMTP relay. Direct access to the target’s port 25 is not required; the email reaches the target through standard MX routing. Exim receives the email. The virtual_user router strips the +x-attachment-1-y suffix, verifies that {localpart}@{domain} is a valid virtual email account, and routes the message to the dovecot_virtual_delivery transport. The rcpt_include_affixes option passes the full address (including suffix) to Dovecot. Dovecot LMTP receives the message. Because lmtp_save_to_detail_mailbox = yes , it targets the mailbox named after the suffix: x-attachment-1-y . Because lda_mailbox_autocreate = yes , Dovecot creates the Maildir folder: /home/{user}/mail/{domain}/{localpart}/.x-attachment-1-y/cur/ /home/{user}/mail/{domain}/{localpart}/.x-attachment-1-y/new/ /home/{user}/mail/{domain}/{localpart}/.x-attachment-1-y/tmp/ The folder name .x-attachment-1-y contains the string -attachment-1-y , which satisfies the CalDAV regex ^/.+-attachment-(.+)-(.+)$ . The new/ subdirectory provides the additional directory level needed for traversal depth. There are real constraints towards this working in the wild. You must know a valid email address registered as a “virtual user” i.e. via cPanel’s email accounts feature, and you must be able to send an email there. Catch all emails will not work with this technique. Automating The Exploit From our experience, the exploit for this is not as reliable or brutal as the authentication bypass vulnerability. Without knowing a valid email address for a cPanel virtual email user, the exploit becomes much more difficult. There are no clear ways to enumerate these virtual users, despite our many attempts to discover an information leak, or oracle. Within our customer environments, out of a sample size of 200 cPanel hosts with the cpdavd ports open, we had about 20 successful hits wh