rdblue opened a new issue, #16487: URL: https://github.com/apache/iceberg/issues/16487
> This issue was reported to the private Apache Iceberg security mailing list. The submitter is being kept anonymous because the report was sent to a private list. After review, the issue is not considered a serious vulnerability that needs to be kept private, so it is being filed publicly here for tracking and resolution. > > Note: this submission was generated by AI. Please review its claims and source references carefully before acting on them. # Summary The deprecated `/v1/oauth/tokens` route still carries several security-significant problems in the published REST spec. Most importantly, the description explicitly says that the subject token used for token exchange may be "an unsecured JWT token with a sub claim", which makes identity spoofing acceptable by contract. In addition, the route inherits the global `security` requirement instead of declaring `security: []`, and the published OAuth2 security scheme still points `clientCredentials.tokenUrl` at this same deprecated route. # Affected Maven coordinates * primary published spec artifact: `org.apache.iceberg:iceberg-open-api` # Attacker prerequisites * an implementation or generated client that still consumes the deprecated spec route * reliance on the published spec text for auth behavior or gateway policy # Additional spec problems * The operation inherits the global `security` requirement instead of overriding it with `security: []`, so code generators and gateways can model the token-minting endpoint as already protected by the token it is meant to issue. * `components.securitySchemes.OAuth2.flows.clientCredentials.tokenUrl` still points to `/v1/oauth/tokens`, which keeps steering spec consumers toward the deprecated route. * The refresh-style token-exchange guidance says to send the subject token in the `Authorization` header, which makes it too easy for implementations to conflate the token being exchanged with the token that authorizes the request. # Impact * Implementations can accidentally accept forged subject identities. * Generated clients, reverse proxies, or API gateways can mis-handle token acquisition because the endpoint is presented as protected by the same scheme it is meant to mint. * Spec consumers can keep routing bootstrap or refresh flows to the deprecated endpoint because the published OAuth2 security scheme still names it as the token URL. # Proof status I reproduced this locally with a targeted reproducer or exploit. The observed result matches the trigger and impact described above. # Key source references * open-api/rest-catalog-open-api.yaml Current severity assessment [2]: Important [1] https://iceberg.apache.org/security/ [2] https://security.apache.org/blog/severityrating/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
