From the Cisco edition of November 2, 2026
Cisco says SnortML blocked a novel PHP2Shell exploit attempt within 24 hours of disclosure and Splunk now has 10+ post-exploit detections
Cisco (Secure Firewall, Talos, Splunk) · Network security vendor; applies to SLED agencies, campuses and districts running Cisco Secure Firewall and Splunk · Global
- Publisher
- Cisco Blogs
- Original publication
- Cisco Blogs, Nov. 2, 2026
- Source retrieved
- 2026-11-03
What happened
Cisco states that in under 24 hours after PHP2Shell (CVE-2026-109618/109619) disclosure, SnortML, the machine-learning engine in Cisco Firewall 10.1 intrusion prevention, caught and blocked a novel exploit attempt in customer telemetry, alongside day-zero Snort signatures. SnortML is on by default only for 10.1 customers using the security-over-connectivity policy. Cisco also says customers have more than 10 Splunk detections for post-exploit activity. No counts of blocked attempts, false positives or affected customers are given.
Why it matters
Direct for SLED. PHP runs many agency, campus and district web apps (CMS, webmail, portals), and CISA added both CVEs to KEV on Oct. 26. Cisco Firewall and Splunk are common across SLED, so the claim maps to an immediate patch-window question: what blocks exploits while patching is incomplete.
Evidence and measured results
Vendor blog, single unquantified detection anecdote. Independent context: CISA KEV listing (archived) and Wiz telemetry (this edition) showing limited, mostly failed exploitation attempts and fast remediation.
Limitations and uncertainty
Vendor claim; no metrics; one detection event; day-zero claim not independently verified; AI-accelerated-threat framing is asserted, not evidenced in the post.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-03; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Agencies and campuses must protect internet-facing PHP apps during the PHP2Shell patch window.
- Stakeholders
- CISO
- Security operations lead
- Web/application owners
- Network/firewall team
- Discovery questions
- Which internet-facing systems run PHP, including inside vendor products?
- Which Cisco Firewall release and intrusion policy are in use?
- Are Splunk PHP2Shell detections installed and tied to firewall events?
- Value hypothesis
- Bounded: correctly configured firewall ML plus Splunk detections may reduce exposure while patching completes.
- Potential engagement
- A one- to two-week PHP2Shell exposure and compensating-control review.
- Unsupported claims
- That SnortML stops all novel exploits
- Any blocked-attempt or false-positive rate
- That in-line blocking replaces patching
Pre-sales engineering
Role takeaway
- Fit
- Fits SLED estates already on Cisco Secure Firewall 10.1 and Splunk.
- Architecture and integration
- SnortML runs in the firewall IPS engine; Snort rules link to Splunk detections for post-exploit correlation.
- Prerequisites
- Cisco Firewall software 10.1
- Security-over-connectivity policy or explicit SnortML enablement
- Splunk ES with current detection content
- Constraints
- Older firewall releases lack SnortML
- Not applicable to non-Cisco perimeters
- No coverage for unpatched internal hosts not traversing the firewall
- Security
- Compensating control only; follow CISA KEV guidance to patch or isolate.
- Proof of value
- Run detect-mode SnortML on PHP traffic and measure false positives
- Replay public PoC traffic in a lab to confirm block and Splunk alert
- Confirm detection mapping in Splunk
Delivery
Role takeaway
- Work
- PHP inventory, patch tracking, SnortML verification and Splunk detection deployment.
- Dependencies
- Asset inventory
- Firewall upgrade path to 10.1
- Splunk content updates
- Ownership
- Customer security operations; application owners own patching.
- Skills and adoption
- SOC analysts need tuning skills for ML-based IPS alerts.
- Governance checkpoints
- Change approval before enabling in-line block
- Review of false positives after one week
- Acceptance criteria
- Proposed: 100% of internet-facing PHP hosts patched or isolated
- Proposed: lab PoC replay produces a Splunk alert
- Risks
- Version gaps leave SnortML off
- Alert noise causes rule disablement
- False sense of safety delays patching
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
SnortML coverage depends on Firewall software 10.1 and the security-over-connectivity policy; older releases or balanced policies may not have it enabled by default.
Governance
Who approves, reviews and stays accountable for outcomes?
Treat in-line ML blocking as a compensating control, not a patch substitute; CISA guidance still says patch or take systems offline.
Security and privacy
What data, permissions and controls need testing?
ML-based in-line blocking can produce false positives on legitimate PHP traffic; the source gives no false-positive data.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
SOC staff in small SLED teams benefit from pre-built detections, but tuning ML alerts takes skills.
Procurement
What should contracts, pricing and exit terms secure?
Firewall 10.1 upgrades or Splunk ES content may be needed; verify entitlement before quoting.
Operating model
Which teams own the service once it runs?
Interlocks network and SOC teams; requires clear patch ownership by app owners.
Publication history
- 2026-11-02Cisco · Issue 054 resources
Stable resource ID: cisco-php2shell-snortml-splunk-detections-20261102