How severe is GHSA-9wgg-m99q-hhfc?

GHSA-9wgg-m99q-hhfc has a CVSS score of 8.1/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-9wgg-m99q-hhfc?

GHSA-9wgg-m99q-hhfc affects the following packages: emailproxy (PyPI). Ecosystems affected: PyPI.

How do I fix GHSA-9wgg-m99q-hhfc?

Update emailproxy to 2023.12.19 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9wgg-m99q-hhfc is resolved across your whole dependency graph.

How do I detect GHSA-9wgg-m99q-hhfc in my PyPI dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for emailproxy. 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.

How do I mitigate GHSA-9wgg-m99q-hhfc if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-9wgg-m99q-hhfc?

O3 pinpoints whether GHSA-9wgg-m99q-hhfc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-9wgg-m99q-hhfc actively exploited in the wild?

No public exploit code has been indexed for GHSA-9wgg-m99q-hhfc yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-9wgg-m99q-hhfc published, and has it been updated?

GHSA-9wgg-m99q-hhfc was published on December 19, 2023 and was last updated on November 28, 2024. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐍 PyPI

GHSA-9wgg-m99q-hhfc

HIGH

Expired tokens can be renewed without validating the account password

Published

Dec 19, 2023

Updated

Nov 28, 2024

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🐍emailproxy

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Impact

In versions of the proxy from 2022-09-05 onwards (since 8c874c2ff3d503ac20c7d32f46e08547fcb9e23f), expired OAuth 2.0 client credentials grant (CCG) flow authorisation tokens could be renewed automatically without checking their validity against the original account configuration (i.e., the password that was set up when first creating an account in the proxy).

An attacker with knowledge of valid account addresses and careful timing (specifically, attempting to log in during a period from 10 minutes prior to the token expiry time, but before a genuine login request is received) could use this issue to gain access to an account.

This issue is only a security concern if you use the proxy with the CCG flow and no additional account secret encryption (see below). If this is the case, it is particularly important to update if you use the proxy in a publicly-accessible setting (i.e., it is available from the internet or across a network). To fix the issue you should switch to version 2023-12-19 or later of the proxy immediately.

If you use this flow, but have also set encrypt_client_secret_on_first_use = True and removed the original client_secret value from the proxy's configuration file then this issue is not a concern.

For all other use-cases (e.g., a normal interactive account authentication, or the ROPCG flow), this issue is also not a concern. However, it is always recommended as best practice to keep the proxy up-to-date.

Patches

Email OAuth 2.0 Proxy version 2023-12-19 (commit eaaa1a2e7a132bf0958dd2f99a749ad98e3212aa) fixes this issue.

Issue details

Because it was originally designed for use as an interactive, local-only service on a single device, the proxy automatically resets account access tokens if incorrect IMAP/POP/SMTP login details are provided. For public-facing deployments, the delete_account_token_on_password_error option is provided, and can be set to False to disable this behaviour, which would normally be only a nuisance, rather than a security risk.

Regardless of this option's value, the proxy encrypts locally-stored tokens, and requires interactive re-authentication (or, with the resource owner password credentials grant (ROPCG) flow, the correct remote account password) to renew tokens if they expire or are reset. The proxy's token retrieval implementation was created with this interactive process in mind.

The CCG flow is an administrator-level method that grants broad access without user knowledge or consent – no user interaction (or remote account password) is ever required. From 8c874c2ff3d503ac20c7d32f46e08547fcb9e23f until the fix in eaaa1a2e7a132bf0958dd2f99a749ad98e3212aa, when CCG tokens neared their expiry date (or had already expired), and the original unencrypted client_secret value was available they were automatically reset, renewed and encrypted with the given login password, but without checking whether that password was actually able to decrypt the existing token.

Detecting unauthorised access

If you do not use the OAuth 2.0 CCG flow (which is currently only known to be supported by O365), unauthorised account access was not possible.¹ Attempts to exploit this flaw will be revealed in the same way as any other malicious access: an unexpected reauthorisation prompt from the proxy when trying to log in with the legitimate account details.

When using the CCG flow, if you have set delete_account_token_on_password_error = False, unauthorised access will be revealed by the presence of an unexpected login failure from the proxy when attempting to log in with the correct password.

It you have not set this value, it is not possible to detect unauthorised access in O365 CCG mode except via AAD/Entra or other external logs. However, it is also worth reiterating that the CCG flow should never be used in a publicly-accessible context due to the significant and potentially dangerous account control it provides.

Footnotes

If you are using a provider that does not provide an OAuth 2.0 refresh token (or have configured your account's scope so that this is not present), it is possible to trigger the line of code that caused this issue, but there is no way to use it for account access because interactive authentication is still required. ↩

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐍PyPI	`emailproxy`	all versions	2023.12.19

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for emailproxy. 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 emailproxy to 2023.12.19 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9wgg-m99q-hhfc 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-9wgg-m99q-hhfc 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-9wgg-m99q-hhfc. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Impact In versions of the proxy from `2022-09-05` onwards (since 8c874c2ff3d503ac20c7d32f46e08547fcb9e23f), expired OAuth 2.0 client credentials grant (CCG) flow authorisation tokens could be renewed automatically without checking their validity against the original account configuration (i.e., the password that was set up when first creating an account in the proxy). An attacker with knowledge of valid account addresses and careful timing (specifically, attempting to log in during a period from 10 minutes prior to the token expiry time, but before a genuine login request is received) cou

O3 Security · Impact-Aware SCA

Is GHSA-9wgg-m99q-hhfc in your dependencies?

O3 detects GHSA-9wgg-m99q-hhfc across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works