Version 6.5 of OpenApi-Generator: Vulnerability BDSA-2023-0962 [CWE-918]

[jturlington]

Vulnerability description OpenAPI Generator contains a server side request forgery (SSRF) vulnerability. A remote unauthenticated attacker could exploit this vulnerability by using a crafted API request in order to view sensitive information or access resources on the network that they do not have permission to access.

[veryriskyrisk]

Is it about this one -> https://notes.sjtu.edu.cn/s/2_yki_2Xq ? I'm having hard time understanding how's that a vulnerability. Isn't like saying that wget has a SSRF vulnerability because when you type wget myserverz.hackorz.com it's sending DNS request 🤔 ?

[aviraonepiece]

Is this fixed in version 6.5?

[martin-mfg]

It seems this is not fixed yet. For reference, the CVE number for this vulnerability is CVE-2023-27162.

It would be nice if somebody could contribute a fix for this problem. As a starting point, the user-provided URL is used here. Before reading from this URL, some security checks need to be added which ensure that we're not accessing any internal resources.

Is it about this one -> https://notes.sjtu.edu.cn/s/2_yki_2Xq ? I'm having hard time understanding how's that a vulnerability. Isn't like saying that wget has a SSRF vulnerability because when you type wget myserverz.hackorz.com it's sending DNS request 🤔 ?

If the provided URL points to a publicly available resource, everything is fine. However, the provided URL could potentially also point to something like http://localhost/secretfile or file:///my/local/secret/file. And currently OpenAPI Generator would happily open these files and potentially leak their contents to the user.

[jwson-automation]

is any update about this CVE-2023-27162 vulnerability?

[wing328]

Is it about this one -> https://notes.sjtu.edu.cn/s/2_yki_2Xq ? I'm having hard time understanding how's that a vulnerability. Isn't like saying that wget has a SSRF vulnerability because when you type wget myserverz.hackorz.com it's sending DNS request 🤔 ?

agreed with @veryriskyrisk

likewise curl has the same vulnerability

as stated in the project's readme, users should definitely reviewed the input before running the generator.

we will mark this as "closed as not planned"

[martin-mfg]

agreed with @veryriskyrisk

likewise curl has the same vulnerability

as stated in the project's readme, users should definitely reviewed the input before running the generator.

we will mark this as "closed as not planned"

Hi @wing328, I think there's a misunderstanding. The vulnerability is not in local code generation. Instead the problem is that I could go to https://api-latest-master.openapi-generator.tech/index.html, provide this input

{
  "openAPIUrl": "http://localhost/etc/passwd",
[...]
}

And the server would then leak the contents of its /etc/passwd to me.

In reality the POST /api/gen/clients/{language} endpoint of this website seems to be broken. (And maybe /etc/passwd is not accessible on the server, but then I could still access other secret server files.) Either way, reviewing input specs doesn't apply to this scenario.

Therefore I suggest reopening this issue. :)

[wing328]

i did a test with the latest master of the online openapi generator

 % curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' \
-d '{"openAPIUrl": "http://localhost/etc/passed"}' \
'http://api-latest-master.openapi-generator.tech/api/gen/clients/ruby'
{"timestamp":"2025-05-09T10:18:32.764Z","status":400,"error":"Bad Request","message":"The OpenAPI specification supplied was not valid","path":"/api/gen/clients/ruby"}%    

i don't think i could reproduce the issue. maybe i'm not doing it the "right" way.

can you show the exact command to reproduce the issue?

[martin-mfg]

can you show the exact command to reproduce the issue?

No, I assume in the existing setup of https://api-latest-master.openapi-generator.tech/ this vulnerability is irrelevant. Because probably on the server hosting https://api-latest-master.openapi-generator.tech/ there is no secret OpenAPI spec file nor any internal endpoint which triggers admin-only operations. If you want I could set up a demo locally or one some free hoster to demonstrate the vulnerability. But I guess that's not what you want.

If anyone else is using openapi-generator-online to host a website like https://api-latest-master.openapi-generator.tech/ anywhere (rather unlikely), and their server has access to some internal resources or admin-endpoints (arguably also somewhat unlikely), then the vulnerability becomes relevant.

My suggestion to reopen the issue was based on the fact that generally there is a vulnerability, which should never be the case from an engineering or perfectionst view. However, from a pragmatic point of view this is not so important, because it's unlikely that this vulnerability can be exploited in practice.

[wing328]

Thanks for the detailed explanation.

Here is how I would like to handle this at the moment.

We document this as a known issue (via this issue #15311). Users should NOT be hosting the online generator that has access to internal/other networks. If they're not entirely sure their network setup or this particular issue, they should consider using other ways instead such as CLI.

Of course if anyone can come up with a way to prevent the online generator from accessing internal networks, we welcome a PR with such enhancement.

[martin-mfg]

Sounds good to me. 👍

In case anyone wants to work on this: This might be a good starting point.