GHSA-23x4-m842-fmwf
CRITICALCreation of Temporary File in Directory with Insecure Permissions in the OpenAPI-Generator online generator
Blast Radius
org.openapitools:openapi-generator-onlineReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Impact
On Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory.
This vulnerability is local privilege escalation because the contents of the outputFolder can be appended to by an attacker. As such, code written to this directory, when executed can be attacker controlled.
openapi-generator-online creates insecure temporary folders with File.createTempFile during the code generation process. The insecure temporary folders store the auto-generated files which can be read and appended to by any users on the system.
Vulnerable Code
This vulnerability exists due to a race condition between the deletion of the randomly generated temporary file and the creation of the temporary directory.
File outputFolder = File.createTempFile("codegen-", "-tmp"); // Attacker knows the full path of the file that will be generated
// delete the file that was created
outputFolder.delete(); // Attacker sees file is deleted and begins a race to create their own directory before the code generator
// and make a directory of the same name
// SECURITY VULNERABILITY: Race Condition! - Attacker beats the code generator and now owns this directory
outputFolder.mkdir();
Patches
The issue has been patched by changing the underlying logic to use Files.createTempFile and has been released in the v5.1.0 stable version.
This vulnerability has the same root cause as CVE-2021-21363 from the swagger-api/swagger-codegen project as this project and that one both share the same original source tree.
See: https://github.com/swagger-api/swagger-codegen/security/advisories/GHSA-pc22-3g76-gm6j
For more information
If you have any questions or comments about this advisory:
- Open an issue in OpenAPI Generator Github repo
- Email us at [email protected]
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.openapitools:openapi-generator-online | all versions | 5.1.0 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.openapitools:openapi-generator-online. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update org.openapitools:openapi-generator-online to 5.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-23x4-m842-fmwf is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-23x4-m842-fmwf is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-23x4-m842-fmwf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-23x4-m842-fmwf in your dependencies?
O3 detects GHSA-23x4-m842-fmwf across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.