GHSA-xrjc-c68j-hp7w PrivateBin has reflected JSON injection in backend responses via unescaped REQUEST_URI

• Packagist privatebin/privatebin: < 2.0.5 → fixed in 2.0.5

Vulnerability Details A reflected JSON injection allows an attacker to return arbitrary data in the JSON endpoints (like ` /?jsonld=` and `/?pasteid`). Root Cause `Request::getRequestUri()` sanitizes `$_SERVER['REQUEST_URI']` with `FILTER_SANITIZE_URL`: ```php public function getRequestUri() { $uri = array_key_exists('REQUEST_URI', $_SERVER) ? filter_var($_SERVER['REQUEST_URI'], FILTER_SANITIZE_URL) : ''; return empty($uri) ? '/' : $uri; } ``` `FILTER_SANITIZE_URL` does not strip `"`, `'`, `` characters (per the PHP manual's allowed-character list for this filter). So the raw, attacker-controlled request URI (including query string) passes through almost unmodified into `Controller::$_urlBase` (set in `_init()`). In `Controller::_jsonld()`, `$_urlBase` is spliced directly into one of the static `.jsonld` templates (`js/types.jsonld`, `js/paste.jsonld`, etc.) with a plain `str_replace()`, without any JSON-escaping: ```php $content = str_replace( '?jsonld=', $this->_urlBase . '?jsonld=', file_get_contents($file) ); ... header('Content-type: application/ld+json'); header('Access-Control-Allow-Origin: *'); header('Access-Control-Allow-Methods: GET'); echo $content; ``` A request URI containing a literal `"` therefore breaks out of the JSON string in the `"@context"."pb"` value and injects arbitrary attacker-controlled key/value pairs into the response body, which is served with `Content-Type: application/ld+json` and `Access-Control-Allow-Origin: *`. Additionally, the `jsonld` case in `Controller::__construct()` returns early: ```php case 'jsonld': $this->_jsonld($this->_request->getParam('jsonld')); return; ``` This bypasses `_setCacheHeaders()` and all of the security headers normally applied in `_view()` (notably `X-Content-Type-Options: nosniff`, CSP, `X-Frame-Options`, `Referrer-Policy`). So this is the only response path lacking `X-Content-Type-Options: nosniff`. Attack Scenario 1. An attacker crafts a request to the target PrivateBin instance whose request-target contains a raw `"` character, e.g.: `GET /?jsonld=types&x="injected":"pwned","y":" HTTP/1.1` (delivered via a raw socket / HTTP client that doesn't normalize the request line — most browsers percent-encode `"` in the address bar, but many HTTP libraries, proxies, and automated link-preview/structured-data crawlers do not). 2. The server reflects the raw value into the JSON-LD response, producing a syntactically broken / attacker-extended JSON document. 3. Because `Access-Control-Allow-Origin: *` is set and `X-Content-Type-Options: nosniff` is missing on this path, any origin can fetch and rely on this manipulated content, and the response loses the defense-in-depth MIME-sniffing protection applied everywhere else in the app. Impact Reflected, unauthenticated injection of attacker-controlled content into a CORS-open `application/ld+json` response, plus a missing `X-Content-Type-Options: nosniff` header on this single response path (present everywhere else). No direct script execution was demonstrated on current browsers (this content type is generally not HTML-sniffed), but it is a real output-encoding bug (CWE-116) and a defense-in-depth gap that could be exploited by structured-data consumers or in combination with other issues / less-strict clients. Vulnerable Code ```php $content = str_replace( '?jsonld=', $this->_urlBase . '?jsonld=', file_get_contents($file) ); ... header('Content-type: application/ld+json'); ``` Verification Dynamically confirmed on v2.0.4 (commit `597a6f0`) via `php -S 127.0.0.1:8082 index.php`: Request: ```http GET /?jsonld=types&x="injected":"pwned","y":" HTTP/1.1 Host: 127.0.0.1:8082 Connection: close ``` Unpatched response body (excerpt): ```json "pb": "/?jsonld=types&x="injected":"pwned","y":"?jsonld=types#" ``` — i.e. the `"` characters are reflected raw, breaking the JSON structure, and `X-Content-Type-Options` is absent from the response headers. After applying the fix above, the same request returns: ```json "pb": "/?jsonld=types&x=\"injected\":\"pwned\",\"y\":\"?jsonld=types#" ``` with `X-Content-Type-Options: nosniff` present, and the existing `JsonApiTest::testJsonLd*` unit test expectations (`/?jsonld=...`) remain unchanged for normal requests. Credits This vulnerability was reported by Iaohkut, @alanturing881, which PrivateBin would like to thank for that. In general, PrivateBin would like to thank everyone reporting issues and potential vulnerabilities to it. If you think you have found a vulnerability or potential security risk, we'd kindly ask you to follow our security policy and report it to us. PrivateBin then assess the report and will take the actions PrivateBin deem necessary to address it.