{"answers":{"affected":"2 open source packages ship an affected version, including org.owasp.esapi:esapi.","exploited":"There is no known exploitation of GHSA-7c2q-5qmr-v76q in the wild and no public exploit code.","fix":"Upgrade org.owasp.esapi:esapi to 2.5.2.0 or later.","what":"GHSA-7c2q-5qmr-v76q is a vulnerability in org.owasp.esapi:esapi, published on 27 Oct 2023."},"fix_prompt":"Check this codebase for GHSA-7c2q-5qmr-v76q and fix it if it is affected.\n\nWhat it is: GHSA-7c2q-5qmr-v76q is a vulnerability in org.owasp.esapi:esapi, published on 27 Oct 2023. \nExploitation: There is no known exploitation of GHSA-7c2q-5qmr-v76q in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- org.owasp.esapi:esapi (Maven): affected all versions; fixed in 2.5.2.0\n- org.owasp.esapi:esapi (Maven): affected all versions; fixed in 2.5.2.0\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-7c2q-5qmr-v76q/ (Markdown: https://insights.sbomify.com/GHSA-7c2q-5qmr-v76q/index.md)","id":"GHSA-7c2q-5qmr-v76q","markdown":"https://insights.sbomify.com/GHSA-7c2q-5qmr-v76q/index.md","name":"GHSA-7c2q-5qmr-v76q","record":{"aliases":[],"analysis":null,"analysis_generated_by":null,"assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"### Impact\nESAPI 2.5.2.0 and later addressed  the DoS vulnerability described in CVE-2023-24998, which Apache Commons FileUpload 1.5 attempted to remediate. But while writing up a new security bulletin regarding the impact on the affected ESAPI `HTTPUtilities.getFileUploads` methods (or more specifically those methods in the `DefaultHTTPUtilities` implementation class), I realized that a DoS vulnerability still persists in ESAPI and for that matter in Apache Commons FileUpload as well.\n\n### Related to\nCVE-2023-24998\n\n### Patches\nESAPI 2.5.2.0 or later.\n\n### Workarounds\n- See the 'Solutions' section of Security Bulletin 11, in the References section. If you are not using ESAPI file uploads, see also the 'Workarounds' section.\n- Deploy an external WAF or other suitable DoS protection.\n- Add additional defenses to your code using HTTPUtilities.getFileUpload, such as requiring prior authentication, restricting how many / much content can be uploaded per user per day or per hour, etc. (It is the opinion of the ESAPI development team that such required controls should not be added to ESAPI because it is a general purpose security library and thus ESAPI ought not be enforcing generic policies like these on everyone, especially it it could break existing code bases.)\n\n### References\n[Security Bulletin 11: How Does CVE-2023-24998 Impact ESAPI?](https://github.com/ESAPI/esapi-java-legacy/blob/develop/documentation/ESAPI-security-bulletin11.pdf)\nNew ESAPI 2.5.2.0  or later Javadoc on HTTPUtilities.getFileUploads: https://javadoc.io/static/org.owasp.esapi/esapi/2.5.2.0/org/owasp/esapi/HTTPUtilities.html#getFileUploads-javax.servlet.http.HttpServletRequest-java.io.File-java.util.List-\n(Note: This link won't work until the 2.5.2.0 release is made official.)\n\n### Final Word\n(Especially to GitHub Advance Security team / GitHub as a CNA) -- I do not really wish to file a CVE for this. I had originally considered it, but there is no real way to address the general DoS scenarios for file uploads without breaking ESAPI client code which we are not willing to do. The clients have to take some responsibility for this themselves. In the next ESAPI release, I am going to add a reference to the appropriate Javadoc to this GitHub Security Advisory, but that's the best we can do. If you wish to discuss this with me, please first contact me via email at kevin.w.wall@gmail.com.","ecosystems":["Maven"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"DoS vulnerabilities persist in ESAPI file uploads despite remediation of CVE-2023-24998","id":"GHSA-7c2q-5qmr-v76q","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"Maven","product":null,"products":[],"type":null,"year":"2023"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"Maven","fixed":["2.5.2.0"],"introduced":["0"],"last_affected":[],"package":"org.owasp.esapi:esapi","purl":null,"source":"GHSA-7c2q-5qmr-v76q"},{"ecosystem":"Maven","fixed":["2.5.2.0"],"introduced":["0"],"last_affected":[],"package":"org.owasp.esapi:esapi","purl":"pkg:maven/org.owasp.esapi/esapi","source":"GHSA-7c2q-5qmr-v76q"}],"products":null,"published":"2023-10-27","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":null,"url":"https://insights.sbomify.com/GHSA-7c2q-5qmr-v76q/"}