UnratedPublic exploitVulnerability

CVE-2026-115560

Remote Code Execution in PHP Session Serialization and Upload Progress

Updated today

Trending this week#6of 416,524 vulnerabilities

Mention activity · 30 days

179 mentions · peak 90 in a dayToday

CVSS-Not scored

EPSS-30-day exploit probability

CISA KEVNoNot listed

In the wildReported1 exploitation record in Mallory

Vendors: PHP GroupIcewarp

IdentifiersCVE-2026-115560CWE-502

CVE-2026-115560 is a remote code execution vulnerability involving PHP session serialization and session upload-progress tracking, disclosed on October 23, 2026. The vulnerable scenario requires session.serialize_handler to initially use php_binary or php_serialize, followed by application code switching it to php through ini_set() before calling session_start(), while session upload progress remains enabled. This uncommon interaction can expose affected applications to remote arbitrary code execution. Exact affected version ranges and the complete technical root cause have not been publicly established. The vulnerability is separate from the PHP2Shell vulnerabilities CVE-2026-109618 and CVE-2026-109619 and is not fixed by their October 21 security updates.

Do you run this?See affected versions in your environment and whether adversaries are exploiting this vulnerability against assets like yours.

Check your exposure

Analyst brief

Impact, mitigation & remediation

What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.

Impact

What an attacker gets, and what they’ve been doing with it.

Successful exploitation could compromise the affected PHP application and permit arbitrary code execution with the privileges of its PHP or web-server worker process. Consequences can include disclosure or modification of application data and accessible credentials, unauthorized server-side changes, and service disruption. Elevated operating-system privileges are not an established direct consequence. No confirmed exploitation of this specific vulnerability was documented as of October 26, 2026.

Mitigation

If you can’t patch tonight, do this now.

Set session.upload_progress.enabled=0 through a configuration mechanism effective before request processing. Apply it to all relevant PHP service configurations, account for overrides, restart affected PHP workers and web services, and verify the effective setting. Retain this setting if it was previously applied for CVE-2026-109619. Review application code for runtime serializer changes and eliminate the php_binary or php_serialize to php transition before session_start() where possible. Applications that never change the session serialization handler at runtime are not exposed through the disclosed path. Restricting upload endpoints and deploying applicable WAF rules can provide defense in depth but should not replace the vendor-recommended configuration mitigation.

Remediation

Patch, then assume compromise.

Install the permanent PHP fix when it becomes available through the next regular bugfix release or an applicable downstream vendor update. No fixed release was identified as of October 26, 2026. PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 address the earlier PHP2Shell vulnerabilities but do not remediate CVE-2026-115560. Maintain the configuration mitigation pending the dedicated fix, and assess exposure through application code and effective runtime configuration rather than the installed version alone.

Public exploits

Exploits

7 exploits validated by Mallory's analysis. Hidden: 22 rejected by Mallory's analysis as not a working exploit; 1 not yet analyzed, such as Exploit-DB entries.

View more in app →

php2shellStandalone Python repository containing 13 files: three implementation modules, three unittest modules, five documentation/license files, a dependency declaration, and an example target list. poc.py provides check, exploit, and offline build modes, target-list parsing, concurrency, and reporting. php2shell_core.py supplies version parsing, HTTP transport interfaces, multipart builders, and trigger/execution interfaces. php2shell_exploit.py orchestrates multiple paths and stalled, micro, and session-injection variants, retaining the highest-scored result. There are no third-party dependencies. The repository claims to target CVE-2026-109618 and CVE-2026-109619 in PHP session.upload_progress. The default 618 mode primarily tests triggering conditions and session primitives, rather than delivering a demonstrated shell. The optional 619 mode accepts a configurable command but requires build-specific function addresses; documentation describes heap spraying and forged runtime structures. No automatic address disclosure or portable bypass is established by the visible code. Assessment results require caution. A visible upload-progress entry establishes progress handling, not memory corruption; an echoed session identifier can reflect ordinary session behavior rather than an independently exploitable fixation vulnerability. HTTP acceptance and gateway failures are weak indicators. The smart-mode scorer also treats HTTP 301, 302, 403, and 500 as upload_accepted, so this verdict does not establish successful multipart processing. WordPress-specific paths are entry-point guesses, not evidence of a WordPress vulnerability. The code's version thresholds and CVE attribution are repository claims, not independently verified findings. Legacy-version handling also differs from the README: the implementation marks many PHP 5.x/7.x versions likely vulnerable while treating PHP 8.0/8.1 as unknown. Tests cover basic parsing, multipart construction, and target loading, not successful exploitation. Significant portions of php2shell_core.py and poc.py were truncated in the supplied content, preventing full validation of transport, memory-forging, and success-detection logic. No execution was performed. No evidence of a malicious fake exploit, fixed external callback, or exfiltration destination is visible. The original repository URL, revision, and archive size were not provided; their fields use empty/zero placeholders.murrez · Disclosed Oct 21, 2026 · python · web · networkOperational php-cve-2026-115560-demoThis standalone repository supplies an intentionally vulnerable local PHP lab and a Bash exploitation client, rather than a framework module or vulnerability scanner. Its claimed association with CVE-2026-115560 is stated by the README but cannot be independently verified from the supplied material. NimbusDrive 4.8.2 is fictional application branding, not evidence of a real affected commercial product. The 74-file tree contains 21 PHP files, five Bash scripts, one JavaScript file, and one CSS stylesheet counted as code, alongside SVG assets, documentation, configuration mirrors, and runtime placeholders. run.sh prepares the repository-local var tree, selects php_binary or php_serialize, disables upload-progress cleanup, and launches PHP on loopback port 8099. router.php implements clean routes and static-file handling. var/www/app holds shared bootstrap, configuration, rendering, helpers, and upload handling; var/www/html supplies product pages, an upload interface, diagnostics, and three JSON APIs. etc contains illustrative PHP, FPM, nginx, Apache, systemd, cron, and logrotate configurations. The two health scripts are duplicates. The exploit primitive is a session serializer mismatch. Upload-progress processing writes attacker-controlled progress-key bytes before application execution. bootstrap.php then switches the serializer to php and calls session_start(). A pipe delimiter followed by a serialized DemoGadget can cause object instantiation during session decoding; DemoGadget::__wakeup() executes its cmd property with shell_exec(). Authentication is not required by this lab. The text endpoint exposes proof output, while most PHP routes share the same vulnerable bootstrap. poc.sh offers one-shot and interactive command execution, configurable target/session parameters, target-user probing, and automatic local-server startup. Its documented long-command technique writes a helper into the local project tree, so this client workflow assumes a co-located server or shared filesystem and does not establish remote-only exploitation of unrelated hosts. The checked-in helper contains a prior command to read config.php. The claimed key-length and timing behavior comes from repository documentation; with normal upload-progress cleanup, surviving progress data or a race would be needed rather than the lab's deterministic setup. Important limitations: the central payload-generation/request section of poc.sh is truncated in the supplied content, and no runtime validation was performed. The mirrored FPM pool uses php_admin_value for session.serialize_handler, which normally prevents the application's ini_set override and may block the intended mismatch. The startup readiness loop also uses ((i++)) under set -e, which can terminate the client on its first unsuccessful polling iteration. The prompt defaults to a cosmetic www-data label unless configured for the probed identity, despite stronger README claims. run.sh can terminate existing listeners on port 8099 and deletes prior lab sessions/proof artifacts. No reverse-shell callback, exfiltration destination, or external payload download is evident. Repository URL, git reference, and archive size were not supplied; their fields use empty/zero placeholders.prnjlksingh · Disclosed Oct 23, 2026 · php · bash · web · localOperational CVE-2026-115560The repository contains a minimal README and a standalone Python exploit demonstration, poc.py. It claims CVE-2026-115560, but the supplied material does not establish that identifier's validity or identify affected PHP versions. The demonstrated primitive is session-file contamination, not standalone remote code execution. The script sends a manually constructed multipart POST containing PHP_SESSION_UPLOAD_PROGRESS=x, a fixed PHPSESSID=pwnd00000000000001 cookie, and a file part whose filename contains PHP code. It sends 600-byte body chunks with 1.15-second pauses, using 45 chunks by default, to keep the upload-progress session data present longer. It prints Linux session-file locations and suggested local inspection commands. The code states that the session data is cleared after the upload, but does not verify that behavior or successful injection. The PHP payload only prints a marker and PHP_VERSION if another mechanism evaluates it. No file-inclusion request, command shell, persistence, exfiltration, or automatic success check is implemented. The uploader does not read the HTTP response. TLS certificate validation is disabled, and TLS wrapping is selected solely when the destination port is 443, so other HTTPS ports are not handled correctly. URL query strings are also omitted from the request path. The script requires interactive confirmation before starting its upload thread. No exploit framework is present. The payload is hardcoded and basic. Repository URL, Git reference, and archive size were not supplied; the empty repository fields and zero size represent unavailable metadata.sykeops · Disclosed Oct 23, 2026 · python · webOperational B63-POC-CVE-2026-115560This standalone repository contains two Python 3 standard-library exploit drivers, a Docker-based PHP lab, diagnostic probes, and ten captured evidence transcripts. Of 28 listed files, 11 contain code when the Dockerfile is included: four Python files, five PHP files, one Bash script, and one Dockerfile. Four INI profiles configure five isolated lab deployments. The remaining files are documentation, licensing, ignore rules, and evidence. The exploit places a pipe delimiter and serialized object bytes in a multipart upload filename. PHP's upload-progress hook stores the attacker-influenced record using php_binary or php_serialize. The application then switches to the php serializer, whose pipe-delimited parsing exposes the embedded object to unserialization. The lab's App\Cache\FileCache destructor writes attacker-controlled contents to an attacker-selected path, producing a command-executing PHP webshell. The drivers support direct delivery, slow-upload race delivery, automatic fallback, configurable gadget/property names, shell-path mapping, and nonce-based execution verification. The readable variant additionally exposes a custom shell-template option. These are exploitation tools, not detection-only scripts. The supplied transcripts report successful execution on PHP 8.5.12 with both configured serializers, including five direct successes and ten race successes. Negative controls disable upload progress or eliminate the runtime serializer switch while retaining the gadget. Evidence also covers the php_binary key-length limit and driver exit codes. The RCE demonstration depends on an intentionally supplied application gadget and writable PHP-served storage; serializer confusion alone does not establish universal RCE across PHP applications. No fixed external callback or exfiltration service is visible; loopback addresses identify lab targets, and the GitHub URL is a build dependency. Assessment is based on supplied source and transcripts, not independent execution or vendor verification. Both exploit listings and the README are partially truncated, and evidence commands reference older exploit_opt/exploit.py and exploit_readable/exploit.py paths rather than the listed poc filenames. The claimed CVE attribution, vendor-advisory status, and broader affected-version statements therefore remain unverified. The repository URL, git reference, archive location, and archive size were not provided; empty strings and size 0 represent unavailable repository metadata.basesixtythree · Disclosed Oct 23, 2026 · python · php · web · networkOperational php-cve-2026-115560-kitThis standalone six-file repository contains a loopback-only exploit demonstration and a companion exposure audit. Five files contain code: a Python client, two shell scripts, and two PHP target files; README.md documents the setup and claimed advisory context. run.sh creates a temporary session store and launches PHP's built-in server with php_binary serialization and persistent upload-progress entries. exploit.py uses raw TCP sockets to send two HTTP requests with a fixed session cookie. First, a multipart POST places a serialized object inside an upload-progress key. Second, a GET reaches application code that switches session.serialize_handler to php before starting the same session. The resulting grammar mismatch can deserialize attacker-controlled bytes and invoke DemoVuln::__wakeup(). The gadget only prints a marker and attacker-supplied note. The documentation reports that decoding subsequently fails on trailing data and destroys the session, but the gadget has already executed; it identifies a session_start decode warning as a detection artifact. audit-cve-2026-115560.sh separately inspects configuration and application source, discovers PHP binaries, and offers text or JSON reporting. Its documentation describes per-SAPI configuration and patch-version checks, but the supplied script is truncated through part of that implementation, limiting verification. The visible runtime-switch search does not establish that a match specifically switches to php before session_start(), so audit results require contextual review. The code implements a concrete object-injection demonstration, not merely a detector, but does not implement arbitrary command execution or a production gadget chain. All exploit traffic goes to loopback; documentation and comment URLs are references rather than contacted services. The CVE attribution, reported successful PHP version, and claimed patched releases are repository assertions, not independently verified findings. No repository URL, revision, or archive size was supplied; empty metadata and a zero size represent unavailable values.slabbdev · Disclosed Oct 23, 2026 · python · bash · webOperational CVE-2026-115560This standalone repository contains a Python exploit client, a Bash lab manager, three PHP endpoints, Docker build/Compose files, two PHP configurations, and supporting documentation and metadata: 15 files total, including five executable source files. The claimed vulnerability identifier and reported successful testing against PHP 8.4.27 come from repository content and have not been independently verified. The visible producer sends a slow multipart upload containing an attacker-chosen PHPSESSID, a PHP_SESSION_UPLOAD_PROGRESS value beginning with a pipe and serialized object, and a large dummy file named legit.bin. Upload-progress processing is intended to write that value into a session key using the server-configured serializer. A concurrent request to index.php switches the serializer to php before session_start(), causing the embedded pipe to be interpreted as a key/value delimiter and exposing the following bytes to deserialization. The supplied LabGadget executes its cmd property in its destructor. The repository claims destruction occurs even when overall session decoding fails. Slow upload pacing keeps the injected progress key available before normal upload cleanup removes it. The client exposes check and exploit modes, configurable commands and endpoint paths, upload pacing, upload size, and timeout options. Its gadget and proof directory are lab-specific; exploitation of another application would require a suitable available gadget and compatible output handling. The visible transport uses raw sockets and HTTPConnection: stripping https:// from an argument does not implement HTTPS. Serialization lengths use Python character counts, which can be incorrect for non-ASCII command bytes. The Docker lab supplies vulnerable and mitigated services on loopback ports 8094 and 8097. index.php intentionally implements the dangerous handler switch and gadget; noswitch.php omits the switch; info.php exposes global session settings. Disabling session.upload_progress.enabled at server configuration level is the included mitigation. No external callback, exfiltration server, or reverse-shell payload is visible. Documentation and citation URLs are references rather than runtime exploit destinations. The supplied poc.py content is explicitly truncated, preventing full validation of the consumer loop, configuration checks, command-output redirection, and proof polling. No execution was performed. The Git reference and archive size were not supplied; ref is empty and size_bytes=0 represents unavailable metadata, not a measured empty archive.googlesky · Disclosed Oct 24, 2026 · python · bash · web · networkOperational CVE-2026-115560This standalone repository contains an exploit, a configuration checker, a Docker-based reproduction environment, verification scripts, and defensive detection rules. Its claimed vulnerability is CVE-2026-115560: attacker-controlled upload-progress data written with one PHP session serializer is subsequently interpreted with another, potentially causing PHP object injection and command execution. The supplied source supports analysis of the intended mechanism, but no execution results or independently verified advisory information are available here; the claimed CVE, affected-version range, patch status, and real-world impact remain unverified. poc.py uses only Python standard-library modules. It creates an attacker-selected session ID, submits it in a multipart PHPSESSID field, and places a pipe-prefixed serialized LabGadget in PHP_SESSION_UPLOAD_PROGRESS. A producer thread sends a 256 KiB file in 16 KiB chunks with 150 ms delays, while a consumer thread sends GET requests approximately every 50 ms with the matching session cookie. It retries the race and polls a command-derived output URL. The command is configurable, but the gadget and output-file convention are specific to this lab; the repository supplies no real-application gadget chain, reverse shell, persistence, or external callback infrastructure. Although urllib can make HTTPS GET requests, the producer uses an unencrypted socket and defaults to port 80, so HTTPS exploitation is not implemented correctly. The lab uses php:8.4.27-apache. index.php defines a deliberately dangerous destructor gadget and changes the serializer from the configured php_serialize to php before session_start(). info.php exposes session settings as JSON. noswitch.php retains the gadget but omits the serializer change as a negative-control endpoint. Two INI files distinguish upload-progress-enabled and disabled configurations, and Docker Compose exposes the vulnerable and mitigated services only on loopback ports 8094 and 8097. setup.sh manages these services. verify.sh attempts repeated exploitation and a mitigated-target comparison, but its set -e behavior can terminate the script when an expected exploit failure returns nonzero, undermining the intended dashboard and negative-control flow. check.py is a non-exploiting, lab-oriented precondition checker, not a general remote RCE detector. It depends on the custom info.php JSON and index.php response format, does not establish gadget availability, and can label a target NOT VULNERABLE when all configuration probes are unknown. Exploit success reporting also has a weakness: command-output filenames are deterministic and are not cleared or tied to a fresh attempt, so stale files can produce false success reports, particularly during repeated verification runs. The detection directory contains two Suricata signatures and two Sigma-style rules covering multipart upload-progress object patterns and session-decoding errors. Their inclusion does not make the exploit part of a framework. Body-based rules require access to request-body telemetry, and the second Sigma rule has a non-UUID identifier that may fail validation. The remaining files are README documentation and an MIT license. Eight files are counted as executable/build code: two Python scripts, two Bash scripts, three PHP endpoints, and one Dockerfile. README content is partially truncated. The repository URL is inferred from its attribution; no git reference or archive byte size was supplied, so those metadata fields use empty and zero placeholders.al4n4n · Disclosed Oct 25, 2026 · python · bash · web · networkOperational

Exposure surface

Affected products & vendors

Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.

VendorProductType

IcewarpServerapplication

PHP GroupPhpapplication

External references

References

MITRE CVEcve.org · CVE-2026-115560 NVDnvd.nist.gov/vuln/detail/CVE-2026-115560 MITRE CWE · CWE-502cwe.mitre.org

Activity feed

Recent activity

181 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.

View more in app →

gm csirtNews · Oct 27, 2026Security Advisory (Update): Newly Disclosed Remote Code Execution Vulnerability in PHP Session Handling (CVE-2026-115560) - gmcsirtA potential remote code execution vulnerability involving PHP session serialization and session upload progress. Exposure requires session.serialize_handler to initially be php_binary or php_serialize, then change to php through ini_set() before session_start(), while session.upload_progress.enabled remains enabled. Successful exploitation could allow code execution on the web server. No CVSS score or permanent patch is reported. The temporary mitigation is to set session.upload_progress.enabled = 0, reload or restart affected services as necessary, and verify the effective configuration.Read more ↗bleeping computerNews · Oct 27, 2026CISA confirms PHP2Shell vulnerabilities now exploited in attacksA separate PHP remote code execution vulnerability requiring an unusual combination of configuration and application code. The article states that mitigation guidance is available but no patch exists. It does not report exploitation of this vulnerability.Read more ↗socprime blogNews · Oct 26, 2026CVE-2026-115560: Unpatched PHP RCE VulnerabilityA potential remote code execution vulnerability in PHP involving session serialization changes and session upload progress. Exposure depends on an uncommon application-specific configuration, not simply the installed PHP version. PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 do not fix it. As of October 26, 2026, the content reports no public proof of concept, no reported exploitation, and no permanent patch. The full root cause, affected version ranges, and severity score remain undisclosed. Administrators can mitigate the disclosed path by setting session.upload_progress.enabled=0 at server level and restarting relevant workers and services.Read more ↗zdnetNews · Oct 26, 2026PHP2Shell : vous n'avez pas encore appliqué le correctif ? Suivez ...An additional PHP remote code execution vulnerability identified during further investigation of PHP2Shell. Exploitation requires session.serialize_handler initially set to php_binary or php_serialize, switched to php at runtime using ini_set() before session_start(), with session upload progress enabled. Disabling session.upload_progress.enabled mitigates the issue. A patch was pending the normal PHP release cycle at the time described.Read more ↗

+26 more in the timeline. Sign up to see them

Do you run this?See affected versions in your environment and whether adversaries are exploiting this vulnerability against assets like yours.

Check your exposure

Mallory platform

The version that knows your environment.

This page is what’s public. Mallory adds the parts that aren’t: which of your assets are affected, which adversaries are exploiting it right now, and which detections to deploy tonight.

Start Free Trial Open in App ↗

Exposure mappingQuery your assets running an affected version, and investigate the blast radius.

Threat actor evidenceEvery report linking this CVE to a named adversary.

Associated malwareMalware families linked to this CVE, with evidence and IOCs.

Detection signaturesYARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.

Vendor-by-vendor mappingCross-references every affected SKU, including bundled OEM variants.

Social activity146Community discussion across Reddit, Mastodon, and other social sources.