What Happened
The PHP security team disclosed CVE-2026-115560, a remote code execution vulnerability affecting PHP installations with specific non-default configurations. No patch is available yet. The team advised administrators to disable session.upload_progress.enabled immediately.
This isn't an isolated incident. PHP's recently patched PHP2Shell vulnerabilities are already being targeted, though no confirmed successful exploits have been reported. This pattern is significant: PHP powers nearly 70% of all websites, and vulnerabilities in this codebase have a wide impact.
Timeline
Initial Disclosure: PHP security team releases advisory for CVE-2026-115560
Mitigation Published: Team recommends setting session.upload_progress.enabled=0
Current Status: No patch available; organizations must rely on configuration changes
Related Context: PHP2Shell vulnerabilities recently patched; active targeting observed
Which Controls Failed or Were Missing
The vulnerability requires a specific combination of configuration and application code to be exploitable. This points to three control failures:
Configuration Baseline Management: Many organizations lack a documented security baseline for their PHP installations. You're likely using whatever came in the container image or what the platform team installed years ago. When the PHP team advises disabling session.upload_progress, how many of your applications have that setting documented?
Vulnerability Monitoring and Response: If you're learning about CVE-2026-115560 from this article instead of your security monitoring process, there's a gap. The PHP security team regularly publishes advisories. Someone on your team should monitor these and correlate them against your inventory.
Defense in Depth: This vulnerability's requirement for specific configuration and code combinations means layered controls could prevent exploitation. Web application firewalls, runtime application self-protection, or input validation frameworks might block the attack vector entirely.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management."
You can't patch what you don't know you're running. This requirement demands you maintain an inventory that includes PHP versions, enabled modules, and security-relevant configuration parameters. When an advisory like CVE-2026-115560 drops, you should be able to query your CMDB and get a list of affected systems within minutes.
NIST 800-53 Rev 5 SI-2 (Flaw Remediation): "The organization identifies, reports, and corrects information system flaws." The control enhancement SI-2(2) specifically requires automated mechanisms for determining system state and identifying vulnerable components.
The "no patch available" scenario is why SI-2 includes time-based remediation requirements with escalation paths. You need a documented process for when vendor patches aren't available: configuration changes, compensating controls, risk acceptance with executive signoff.
ISO/IEC 27001:2022 Annex A.8.8 (Management of Technical Vulnerabilities): "Information about technical vulnerabilities of information systems in use shall be obtained, the organization's exposure to such vulnerabilities evaluated, and appropriate measures taken."
The key phrase is "appropriate measures taken." When a patch doesn't exist, appropriate measures might include disabling functionality (like session.upload_progress), implementing additional monitoring, or temporarily removing affected systems from production. ISO 27001 requires a risk-based process for deciding.
OWASP ASVS v4.0.3 Section 14.2 (Dependency): "Verify that all components are up to date, preferably using a dependency checker during build or compile time."
This verification requirement extends beyond just version checking. It includes configuration state. Your build pipeline should validate that security-relevant PHP configurations match your baseline before deploying to production.
Lessons and Action Items for Your Team
Build a PHP Configuration Baseline Today
Create a secure configuration template for PHP that disables unnecessary features. Start with session.upload_progress.enabled=0 based on this advisory, but don't stop there. Review the PHP documentation for every enabled extension and session handler. If you can't articulate why it's enabled and what breaks if you disable it, turn it off.
Document this baseline in your configuration management system. Every PHP deployment should start from this template, with deviations requiring security review and documentation.
Automate Configuration Validation
Write a script that audits your PHP installations against your baseline. This doesn't require expensive tooling. A simple Python script that SSH's into your servers, runs php -i, and diffs the output against your approved configuration will catch most deviations.
Run this daily. Alert when configurations drift. Better yet, use configuration management tools like Ansible or Chef to enforce the baseline and prevent drift entirely.
Subscribe to Security Advisories at the Source
Don't wait for aggregators or your vendor to tell you about PHP vulnerabilities. Subscribe directly to the PHP security mailing list. Assign someone on your team to triage these advisories within 24 hours of publication.
Create a decision matrix: What severity level triggers emergency patching? What conditions allow you to wait for the next maintenance window? When do you implement workarounds versus accepting risk?
Test Your Workaround Process
You just learned that CVE-2026-115560 has no patch. How long would it take your team to disable session.upload_progress across all PHP installations? If the answer is "I don't know" or "more than 4 hours," you've identified your next tabletop exercise.
Practice deploying configuration changes under time pressure. Document the runbook. Identify who has authority to approve emergency changes to production PHP configurations.
Map Your PHP Attack Surface
You need a complete inventory: every server running PHP, every application using PHP sessions, every configuration that deviates from your baseline. If you're running PHP in containers, this includes every base image in your registry.
This inventory isn't a one-time project. It's a continuously updated asset database that feeds your vulnerability management program. When the next PHP advisory drops, you'll know exactly what's affected within minutes, not days.
The PHP team's advisory for CVE-2026-115560 gave you a specific mitigation. That's the easy part. The hard part is building the processes that let you implement that mitigation quickly and verify it worked. Start there.
