What Happened
On June 30, 2026, Adobe released emergency patches for CVE-2026-48282, a path traversal vulnerability in ColdFusion's Remote Development Services (RDS) component. This vulnerability has a CVSS v3.1 score of 10.0 and allows unauthenticated remote code execution. Attackers don't need credentials or network access. If RDS is enabled, they're in.
Within two hours of the vulnerability details going public, exploitation attempts were detected.
Timeline
June 30, 2026 (morning): Adobe publishes security bulletin and patches for all supported ColdFusion versions.
June 30, 2026 (afternoon, ~2 hours post-disclosure): Security researchers observe active exploitation attempts targeting unpatched ColdFusion servers.
Current: Ongoing exploitation against organizations that haven't applied patches or disabled RDS.
Which Controls Failed
RDS enabled in production environments. RDS is a development feature providing direct database access and file system operations through a web interface. It should be disabled before production deployment, but many organizations never did.
No inventory of enabled services. Without knowing RDS is running, you can't patch it or shut it down. Many organizations running ColdFusion for years had no documented list of which servers had RDS enabled.
Patch deployment lag. Two hours from disclosure to exploitation means your patch window is effectively zero. If you're on a monthly patch cycle, you're already compromised.
Missing network segmentation. RDS shouldn't be reachable from the internet. Even if it's enabled for legitimate development work, it should sit behind a VPN or within isolated dev networks. The quick exploitation indicates RDS was exposed on public-facing servers.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.3 mandates that security vulnerabilities are identified using reliable, industry-recognized sources and that newly discovered vulnerabilities are addressed based on risk. A CVSS 10.0 with active exploitation requires immediate action.
OWASP Top 10 2021: A05:2021, Security Misconfiguration addresses this scenario. Leaving development features enabled in production is a misconfiguration. The guidance explicitly calls out unnecessary features, services, and interfaces as attack surfaces that must be removed.
ISO/IEC 27001:2022 Control 8.8 (Management of Technical Vulnerabilities) requires you to obtain timely information about technical vulnerabilities and evaluate exposure. More importantly, it requires action. Knowing about CVE-2026-48282 isn't enough. You need a process that moves from awareness to remediation in hours, not weeks.
NIST 800-53 Rev 5 CM-7 (Least Functionality) states that you configure systems to provide only essential capabilities and prohibit or restrict the use of functions that aren't required. RDS in production violates this control by default.
Lessons and Action Items
Audit every legacy system for development features. Don't assume previous teams disabled them. Check ColdFusion for RDS, application servers for debug endpoints, and frameworks for profiling tools. Document what you find, then disable everything not required for production.
Here's your audit checklist:
- Review ColdFusion Administrator settings on every server
- Check web.xml and neo-*.xml configuration files for RDS entries
- Scan for /CFIDE/main/ide.cfm and /CFIDE/debug/ paths
- Verify RDS isn't responding on any production IP addresses
- Document the state of RDS (enabled/disabled) in your CMDB
Build a critical patch process that operates in hours. Your standard patch cycle doesn't work for CVSS 10.0 vulnerabilities with active exploitation. You need a separate process that can:
- Identify affected systems within 30 minutes of disclosure
- Test patches in a staging environment within 2 hours
- Deploy to production within 4 hours, or implement compensating controls
If you can't patch immediately, your compensating control is to disable the vulnerable service. For RDS, that means stopping the service and blocking the /CFIDE paths at your web application firewall.
Segment development tools away from production networks. If you need RDS for development work, run it on isolated systems that can't be reached from the internet or production environments. Use VPN access with multi-factor authentication. Log every connection.
Update your configuration management database. You can't protect what you don't know about. Your CMDB should track:
- Which servers run ColdFusion
- Which versions are installed
- Which optional features are enabled
- Who approved those configurations
- When they were last reviewed
This isn't documentation for its own sake. When the next critical vulnerability drops, you need to answer "are we affected?" in minutes, not days.
Test your emergency response. CVE-2026-48282 gave organizations a two-hour window between disclosure and exploitation. Did your team know about the vulnerability within two hours? Did you have the access and authority to disable RDS immediately? If not, you're not ready for the next one.
Run a tabletop exercise. Pick a hypothetical critical vulnerability in one of your legacy systems. Time how long it takes to identify affected systems, make a patch-or-disable decision, and implement that decision. If the answer is longer than four hours, you have process gaps to fix.
The pattern here isn't unique to ColdFusion. Legacy systems accumulate features that made sense in 2010 but create liability in 2026. Your job isn't just to patch CVE-2026-48282. It's to find the next RDS before attackers do.
