Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘
🐘 Packagist
Not in CISA KEV
MEDIUM severity

GHSA-jr4p-4xjh-fwvw

MEDIUMFix: koel/koel#2549

GHSA-jr4p-4xjh-fwvw is a medium-severity (CVSS 6.3) Server-Side Request Forgery (SSRF) vulnerability in phanan/koel. O3 Security confirms whether GHSA-jr4p-4xjh-fwvw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Koel: Server-Side Request Forgery (SSRF) in radio station creation due to missing validation bail

Also known asCVE-2026-50552
Published
Jul 15, 2026
Updated
Jul 15, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-jr4p-4xjh-fwvw.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs6th percentile — riskier than 6% of all scored CVEsHighest risk
0.00%0.22%0.45%0.67%0.2%0.2%0.2%0.2%Jul 26Sep 26Sep 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-jr4p-4xjh-fwvw plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 369,023 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
🐘phanan/koel

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

Description

Summary

Koel v9.5.0 contains a Server-Side Request Forgery (SSRF) vulnerability in the radio station creation endpoint (POST /api/radio/stations). The url field validation rules are declared without the bail keyword, so the HasAudioContentType rule — which issues HTTP requests to the supplied URL — still executes even after the SafeUrl rule has rejected the URL as pointing to a private/reserved address. Any authenticated, non-admin user can therefore coerce the server into making HEAD/GET requests to arbitrary internal hosts.

This is a blind SSRF: the response body is never returned to the client, but the two distinct validation error messages form a reliable internal-network reachability oracle.

Severity

Medium — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N (5.4)

Authenticated (low-privilege) actor; blind SSRF (no response-body exfiltration). Confidentiality (L) reflects the internal reachability oracle; Integrity (L) reflects state-changing internal endpoints that act on GET/HEAD.

Affected Component

  • Version: Koel v9.5.0 (latest release, HEAD b2e9a34, verified 2026-05-30)
  • Endpoint: POST /api/radio/stations
  • Files:
    • app/Http/Requests/API/Radio/RadioStationStoreRequest.php (missing bail)
    • app/Rules/HasAudioContentType.php (unguarded HTTP fetch)

Root Cause

app/Http/Requests/API/Radio/RadioStationStoreRequest.php (lines 25-34):

'url' => [
    'required',
    'url',
    Rule::unique('radio_stations')->where(function ($query) {
        return $query->where('user_id', $this->user()->id);
    }),
    new SafeUrl(),
    new HasAudioContentType(),
],

In Laravel, validation rules within a single attribute run in sequence and do not stop on the first failure unless bail is present or FormRequest::$stopOnFirstFailure is set. Neither is the case here (App\Http\Requests\Request does not override stopOnFirstFailure, and authorize() simply returns true).

For a directly-supplied private/reserved address (e.g. http://169.254.169.254, http://127.0.0.1:6379, http://192.168.0.1):

  1. SafeUrl (app/Rules/SafeUrl.php lines 45-49) calls isPublicHost($uri->host()), fails it, calls $fail(...) and returns. SafeUrl itself does not make a request in this path — good.

  2. Because there is no bail, validation continues to HasAudioContentType.

  3. HasAudioContentType::resolveContentType() (app/Rules/HasAudioContentType.php lines 41-57) issues the request with no IP/host validation of its own:

    private function resolveContentType(string $url): string { try { $response = Http::head($url); // <-- SSRF if ($response->successful()) { return $response->header('Content-Type'); } } catch (Throwable) { }

     // Falls back to a streaming GET
     $response = Http::withHeaders(['Icy-MetaData' => '1'])
         ->withOptions(['stream' => true])
         ->get($url);                               // <-- SSRF
     return $response->header('Content-Type');
    

    }

The rule's own docblock (line 13-14) states "Should be used after SafeUrl to ensure the URL is safe to reach." — that assumption is silently violated by the missing bail.

Authorization Context

The endpoint is reachable by any authenticated user, not just admins:

  • routes/api.base.php line 108 wraps the route group in Route::middleware('auth') only.
  • routes/api.base.php line 268: Route::apiResource('stations', RadioStationController::class).
  • RadioStationController::store() (lines 31-37) carries only #[DisabledInDemo] — no $this->authorize(...), no #[RequiresPlus], no permission check.

Reachability Oracle (Information Disclosure)

HasAudioContentType::validate() returns two distinct messages:

  • Host unreachable / request throws → "The url couldn't be reached." (line 26)
  • Host reachable but Content-Type is not audio/* → "The url doesn't look like a valid radio station URL." (line 32)

By diffing these responses an attacker can enumerate which internal hosts/ports are live behind the firewall (internal host discovery and coarse port scanning).

Proof of Concept

As any regular authenticated user:

POST /api/radio/stations HTTP/1.1
Host: koel.example.com
Authorization: Bearer <regular_user_token>
Content-Type: application/json

{
  "name": "probe",
  "url": "http://127.0.0.1:6379"
}
  • If the internal service answers → "The url doesn't look like a valid radio station URL."
  • If nothing is listening → "The url couldn't be reached."

The server has now issued a HEAD and a streaming GET to 127.0.0.1:6379 despite SafeUrl having rejected it.

Impact

  • Blind SSRF: server-side HEAD/GET to attacker-chosen internal addresses. The response body is never returned to the client, so this cannot directly exfiltrate content (e.g. cloud-metadata bodies).
  • Internal reachability oracle: reliable live-host / open-port discovery via the two distinct error strings.
  • Side-effect requests: any internal endpoint that performs a state-changing action on GET/HEAD can be triggered.

Note on scope: because SafeUrl calls $fail() for a private host, the overall request validation fails (Laravel aggregates all rule failures; a single failure yields a 422), so RadioStationController::store() never runs and no station is persisted. The impact is therefore limited to the out-of-band HEAD/GET requests issued by HasAudioContentType during validation, plus the reachability oracle — it does not chain into a stored station or into the authenticated radio stream proxy via this path.

Recommended Fix

Add bail so HasAudioContentType only runs after SafeUrl passes, restoring the rule's documented precondition:

'url' => [
    'required',
    'url',
    'bail',
    Rule::unique('radio_stations')->where(/* ... */),
    new SafeUrl(),
    new HasAudioContentType(),
],

(Place bail before SafeUrl/HasAudioContentType; the unique check is local DB only and safe to keep ahead of it if preferred.)

Defense in depth

Have HasAudioContentType::resolveContentType() re-validate the host with Network::isPublicHost() (or reuse Network::isSafeUrl()) before issuing any request, so the rule is safe regardless of ordering. The same Network helper is already used by PodcastService for enclosure URLs.

Relationship to CVE-2026-47260

CVE-2026-47260 addressed SSRF via podcast episode enclosure URLs; the current code guards that sink in app/Services/Podcast/PodcastService.php (line 143) with Network::isSafeUrl(). The radio-station path relies instead on the SafeUrl validation rule, but the missing bail lets the adjacent HasAudioContentType fetch run anyway — leaving an SSRF reachable from the same class of untrusted, user-supplied URLs. I have not been able to confirm the exact upstream fix commit for CVE-2026-47260 from the release tarball, so I am presenting this as an independent finding rather than asserting it is the same code change.

Disclosure

  • 2026-05-30: Identified via source review of v9.5.0 (b2e9a34).
  • Verified entirely by source inspection (route middleware, controller, FormRequest base class, and both validation rules). No live PoC was executed against a third-party host.

If the maintainers agree this is a distinct issue, would you consider requesting a CVE identifier for it through GitHub Security Advisories? Happy to provide any further detail or testing.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistphanan/koelall versions9.7.1

Detection & mitigation playbook

Open-source dependency
  1. Detect

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

  2. Fix

    Update phanan/koel to 9.7.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jr4p-4xjh-fwvw is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-jr4p-4xjh-fwvw 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-jr4p-4xjh-fwvw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

Summary Koel v9.5.0 contains a Server-Side Request Forgery (SSRF) vulnerability in the radio station creation endpoint (POST /api/radio/stations). The url field validation rules are declared without the bail keyword, so the HasAudioContentType rule — which issues HTTP requests to the supplied URL — still executes even after the SafeUrl rule has rejected the URL as pointing to a private/reserved address. Any authenticated, non-admin user can therefore coerce the server into making HEAD/GET requests to arbitrary internal hosts. This is a blind SSRF: the response body is never returned to the c
O3 Security · Impact-Aware SCA

Is GHSA-jr4p-4xjh-fwvw in your dependencies?

O3 detects GHSA-jr4p-4xjh-fwvw across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-jr4p-4xjh-fwvw: phanan/koel… | O3 Security