CVE-2024-39899

In v1.5 we introduced the YOURLS server-side proxy. The idea was to allow using the YOURLs URL shortener without running the YOURLs instance without authentication and/or exposing the authentication token to the public, allowing anyone to shorten any URL. With the proxy mechanism, anyone can shorten any URL pointing to the configured PrivateBin instance. The vulnerability allowed other URLs to be shortened, as long as they contain the PrivateBin instance, defeating the limit imposed by the proxy.

Neither the confidentially of existing pastes on the server nor the configuration options including the YOURLs token are affected.

Indicators of exploitation

Check your YOURLs proxy for shortened domains that do not start with your own PrivateBin instance. Also note, that for this to be a result of an exploitation of this vulnerability, somewhere in the URL the base path + ? e.g. https://privatebin.example/? has to appear in the destination URL, as this is what the guard checked for.

Workarounds

• Disable URL shortening, if you have been using it.
• Only the YOURLs proxy is affected. Other URL shortening options either require a public, un-authenticated shortener, or expose the token to the client, which by design allows shortening any URL.

Proof of concept

See the unit test that got introduced to prevent similar regressions for an example of a URL that would circumvent the configured basepath.

Here is an example of how a manual exploitation would work:

In a PrivateBin instance hosted on https://privatebin.example/, with a valid URL YOURLs shortening proxy configuration using a token to prevent un-authenticated short-URL creation, send a URL shortening request for the domain https://attacker.example.com/?q=https://privatebin.example/?foo#bar. attacker.example.com is any attacker controlled, arbitrary domain.

You can do this by sending a GET request to https://privatebin.example/shortenviayourls?link=https%3A%2F%2Fattacker.example.com%2F%3Fq%3Dhttps%3A%2F%2Fprivatebin.example%2F%3Ffoo%23bar, without URL encoding this looks as follows: https://privatebin.example/shortenviayourls?link=https://attacker.example.com/?q=https://privatebin.example/?foo#bar.

On an affected setup, you will get a valid short URL, which when accessed, leads to https://attacker.example.com/?foo#bar, the attackers domain. On a patched system your request will get rejected and only URLs starting with https://privatebin.example/?[...] are allowed for shortening.

Post-mortem

From our limited analysis, the issue has been introduced in commit 0dc9ab7 while refactoring. The use of substr got replaced by strpos. The initial contribution contained no tests, but an implementation without this flaw. All these changes got introduced in a single pull request. This follows many best practices, as tests were added and the refactoring was done in close collaboration with the original author.

In the future, we plan to switch to the more obvious, readable and understandable str_starts_with, which is available since PHP v8. Such a better function naming and insisting on using modern functions would not only result in a better code quality, but would possibly have prevented the issue, but for backwards-compatibility with PHP 7.3, we stay on the old function for now.

Final Thoughts

The project maintainers have always discouraged the use of URL shorteners and users are always safer sharing the complete, long URL to a paste, see our FAQ.

If you need or want to provide a URL shortener option as a PrivateBin instance administrator, YOURLs is the best option available to use with PrivateBin, because it is the only shortener supported, through the proxy mechanism, preventing arbitrarily shortening any URLs. Running a public URL shortener instance and allowing anonymous users shortening arbitrary domains invites the shortener getting abused.

References

• PR to fix the vulnerability: https://github.com/PrivateBin/PrivateBin/pull/1370

Timeline

• 2024-06-28 Issue report by @nbxiglk via email
• 2024-06-29 Vulnerability reproduced by @elrido, mitigation created and shared with maintainers and issue reporter for review
• 2024-07-06 Pull request with mitigation raised

This issue only affects non-standard configurations of PrivateBin. Instances are affected if all of the following conditions are met:

1. The PrivateBin instance enables URL shortening.
2. A YOURLs URL shortener is used and it is configured not to be public and require authentication to shorten URLs.
3. A basepath, the YOURLs proxy mechanism and an authentication token is configured in PrivateBin to use the non-public YOURLs instance.
4. A crafted URL is sent to PrivateBins' YOURLs proxy endpoint with a URL that contains the PrivateBin instance URL as a GET-parameter or as part of the URL-fragment, but doesn't start with the instance URL (a third-party URL)

The root cause is, that the guard clause checking whether the URL to be shortened belongs to your own PrivateBin domain only checks if the PrivateBin instance is contained in the URL but not if it starts with it.

This is a kind of authentication bypass due to incomplete filtering. This has a similar impact like an open redirect except it does not directly redirect, but allows a further hiding of the target URL as is common and known for URL shorteners. If the URL shortener domain used is trusted by it's users, this allows hiding a malicious URL.

The highest impact may be that this can be used for phishing campaigns, by routing users to some kind of fake site mimicking the trusted shortener or PrivateBin domain, which could then extract sensitive data from entered data or similar. That said, this is a general concern with URL shorteners and users are advised to follow general phishing prevention attempts like verifying the domain of the site they are using and using a trusted PrivateBin instance.

CVE-2024-39899 has a CVSS score of 5.3 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.7.4); upgrading removes the vulnerable code path.

Kodem intelligence

The problem has been patched in version 1.7.4 of PrivateBin. In addition to upgrading, users of the YOURLs proxy feature should check for the indicators of exploitation, as outlined above.

1. What is CVE-2024-39899? CVE-2024-39899 is a medium-severity security vulnerability in privatebin/privatebin (composer), affecting versions >= 1.5.0, < 1.7.4. It is fixed in 1.7.4.
2. How severe is CVE-2024-39899? CVE-2024-39899 has a CVSS score of 5.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of privatebin/privatebin are affected by CVE-2024-39899? privatebin/privatebin (composer) versions >= 1.5.0, < 1.7.4 is affected.
4. Is there a fix for CVE-2024-39899? Yes. CVE-2024-39899 is fixed in 1.7.4. Upgrade to this version or later.
5. Is CVE-2024-39899 exploitable, and should I be worried? Whether CVE-2024-39899 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2024-39899 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2024-39899? Upgrade privatebin/privatebin to 1.7.4 or later.