Summary
Kiota's Java and PHP documentation-comment sanitizers can mishandle attacker-controlled OpenAPI descriptions, allowing generated text to escape documentation comments and become source code. If a developer or build pipeline generates, compiles, and loads affected output, injected code may execute in the consuming application or build environment.
Kiota's Java and PHP documentation-comment sanitizers can mishandle attacker-controlled OpenAPI descriptions, allowing generated text to escape documentation comments and become source code. If a developer or build pipeline generates, compiles, and loads affected output, injected code may execute in the consuming application or build environment.
Affected context
The issue can occur when Kiota generates Java or PHP source from OpenAPI documents containing malicious description text and the language-specific documentation-comment sanitizer removes comment terminators without safely neutralizing them. The Java implementation may also remove non-ASCII characters during normalization, potentially causing characters to form a new comment terminator. Exploitation depends on generated output being compiled and loaded for Java or loaded for PHP; the stated affected range is based on the Java defect and does not imply that PHP generation existed in every release.
The issue can occur when Kiota generates Java or PHP source from OpenAPI documents containing malicious description text and the language-specific documentation-comment sanitizer removes comment terminators without safely neutralizing them. The Java implementation may also remove non-ASCII characters during normalization, potentially causing characters to form a new comment terminator. Exploitation depends on generated output being compiled and loaded for Java or loaded for PHP; the stated affected range is based on the Java defect and does not imply that PHP generation existed in every release.
Exploit preconditions
- Attack surface: OpenAPI descriptions processed by Kiota's Java or PHP source generators
- Required access: Ability to influence the OpenAPI document or its documentation fields, plus access to a generation workflow
- Trigger point: Documentation-comment sanitization followed by source generation
- Execution condition: The generated Java output must be compiled and loaded, or the generated PHP output must be loaded
- Why exploitation is possible: Sanitization can leave overlapping characters that reform a documentation-comment terminator, allowing attacker-controlled text to be interpreted as executable source rather than documentation
- Attack surface: OpenAPI descriptions processed by Kiota's Java or PHP source generators
- Required access: Ability to influence the OpenAPI document or its documentation fields, plus access to a generation workflow
- Trigger point: Documentation-comment sanitization followed by source generation
- Execution condition: The generated Java output must be compiled and loaded, or the generated PHP output must be loaded
- Why exploitation is possible: Sanitization can leave overlapping characters that reform a documentation-comment terminator, allowing attacker-controlled text to be interpreted as executable source rather than documentation
Why this happens
The underlying bug is an output-neutralization failure in documentation-comment sanitizers. Instead of encoding or safely preserving comment terminators, the affected logic deletes them, allowing adjacent characters to be recombined into a valid terminator. In Java, additional character normalization can further change the sanitized output and create the same condition. This maps to CWE-94: Improper Control of Generation of Code, because untrusted specification content can cross from documentation data into generated program syntax.
The underlying bug is an output-neutralization failure in documentation-comment sanitizers. Instead of encoding or safely preserving comment terminators, the affected logic deletes them, allowing adjacent characters to be recombined into a valid terminator. In Java, additional character normalization can further change the sanitized output and create the same condition. This maps to CWE-94: Improper Control of Generation of Code, because untrusted specification content can cross from documentation data into generated program syntax.
Potential impact
- Attacker-controlled code may execute in a build environment
- Generated Java or PHP applications may execute injected logic
- Source repositories or generated artifacts may be modified or poisoned
- Build credentials, application data, or deployment secrets could be exposed
- Downstream users may receive compromised generated client code
- Attacker-controlled code may execute in a build environment
- Generated Java or PHP applications may execute injected logic
- Source repositories or generated artifacts may be modified or poisoned
- Build credentials, application data, or deployment secrets could be exposed
- Downstream users may receive compromised generated client code
General mitigation guidance
Mitigation generally focuses on preserving a strict separation between OpenAPI metadata and generated source syntax.
Common defensive patterns include:
- Encode or neutralize comment delimiters rather than deleting them
- Use context-aware escaping for every target language and output position
- Treat OpenAPI documents and descriptions as untrusted input during generation
- Validate generated source with language-aware parsers or compilation checks before use
- Review generated diffs and keep generated artifacts isolated from privileged build steps
- Run generation and compilation with least-privilege identities and restricted filesystem and network access
- Prefer generator implementations that apply centralized, tested output-encoding routines
Mitigation generally focuses on preserving a strict separation between OpenAPI metadata and generated source syntax.
Common defensive patterns include:
- Encode or neutralize comment delimiters rather than deleting them
- Use context-aware escaping for every target language and output position
- Treat OpenAPI documents and descriptions as untrusted input during generation
- Validate generated source with language-aware parsers or compilation checks before use
- Review generated diffs and keep generated artifacts isolated from privileged build steps
- Run generation and compilation with least-privilege identities and restricted filesystem and network access
- Prefer generator implementations that apply centralized, tested output-encoding routines
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis of sanitizers that delete comment markers or perform lossy character normalization
- Code review checks for direct insertion of OpenAPI descriptions into source comments or generated code
- Regression tests using delimiter-like sequences, overlapping characters, and non-ASCII input
- Generated-source scanning for unexpected statements outside documentation comments
- CI policies that require review of generated diffs and isolate code generation from deployment credentials
- Automated security review tools configured to identify code-generation and output-encoding weaknesses
Organizations can look for this issue through:
- Static analysis of sanitizers that delete comment markers or perform lossy character normalization
- Code review checks for direct insertion of OpenAPI descriptions into source comments or generated code
- Regression tests using delimiter-like sequences, overlapping characters, and non-ASCII input
- Generated-source scanning for unexpected statements outside documentation comments
- CI policies that require review of generated diffs and isolate code generation from deployment credentials
- Automated security review tools configured to identify code-generation and output-encoding weaknesses
