In open-source development, responsible security reporting is essential - not just for maintainers, but for the entire ecosystem. The case of CVE-2025-45406 serves as a cautionary example of how an invalid security report can create unnecessary disruption and confusion.

The Timeline

The issue began with the publication of CVE-2025-45406 by MITRE, which claimed a persistent cross-site scripting (XSS) vulnerability in the CodeIgniter4 Debug Toolbar.

Once published, automated tools such as GitHub Dependabot began flagging affected versions of the framework. Additionally, the roave/security-advisories Composer package blocked installations of codeigniter4/framework version <= 4.6.2, assuming a critical vulnerability was present.

The blog post attempting to explain the issue and offer a proof-of-concept only came to our attention after the CVE was published, as it was included in the CVE’s reference section:
“When Debugging Bites Back: Exposing a Persistent XSS in CodeIgniter4”.

However, the conclusions drawn in that post are technically incorrect.

Why This Is Not a Valid Vulnerability

  1. End Users Cannot Influence File Creation
    The Debug Toolbar stores debug data in JSON files, where filenames are generated internally by the framework. These filenames do not use user input, and only files created by CodeIgniter itself can be loaded. External users cannot inject or control these file names.

  2. All Data Is Properly Escaped
    All data displayed in the Debug Toolbar is escaped using the laminas-escaper library automatically - either at the point of output or before being stored in the JSON file. As a result, no raw user input is ever rendered directly in the browser.

  3. The Toolbar Is Disabled in Production
    By default, the Debug Toolbar is disabled in production environments. It is only enabled in the development environment, where access is typically limited to trusted developers. Access to any debugbar endpoints is only possible in the development environment.

  4. Suggested Fixes Don’t Apply to CodeIgniter4
    The blog post recommends applying common protections like sanitizing input and escaping output. However, these protections are already implemented in CodeIgniter4. The article also misunderstands how and when debug data is written and used.

The Damage of an Invalid Vulnerability

Despite being a false alarm, the CVE caused widespread disruption:

  • CI/CD pipelines were interrupted by automated security warnings.
  • Composer-based workflows relying on roave/security-advisories could not install affected versions.
  • Developers lost confidence in the stability and safety of the framework.

What made matters worse was that this could have been avoided entirely by following proper disclosure procedures.

The Importance of Responsible Disclosure

CodeIgniter4 maintains a clear security policy that encourages anyone who finds a potential vulnerability to contact the maintainers before going public. This allows for investigation, verification, and if necessary, an official fix and coordinated disclosure.

Instead, the CVE was published without any prior contact. While the blog post appeared earlier, it is unreasonable to expect maintainers to proactively scour the internet for potential articles claiming vulnerabilities. Regardless, the blog post presents an inaccurate explanation and a proof-of-concept that does not actually demonstrate a valid issue. We have contacted MITRE with a request to revoke or correct the CVE and are currently awaiting a response.

Update: This was successfully disputed by the initial reporter.

Final Thoughts

Security research is a vital part of open-source software health. But when handled irresponsibly, it can cause real damage to projects and users - even when the threat isn’t real.

I urge anyone investigating or reporting vulnerabilities to:

  • Understand how the software actually works
  • Verify whether a real security risk exists
  • Follow the project’s responsible disclosure process

Invalid CVEs don’t make software less secure - but they do waste developer time, damage trust, and disrupt the ecosystem. Security reporting must be accurate, responsible, and grounded in a real understanding of how the software works.

If you believe you’ve discovered a real issue in CodeIgniter4, please follow the project’s official security policy. If, for any reason, this does not work (spam filters can sometimes be overly strict), don’t hesitate to get in touch with one of the project maintainers. We’re always willing to collaborate and act responsibly on verified concerns.