How severe is GHSA-rc6v-5rmx-w5mv?

GHSA-rc6v-5rmx-w5mv has a CVSS score of 2.8/10, rated LOW. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-rc6v-5rmx-w5mv?

GHSA-rc6v-5rmx-w5mv affects the following packages: github.com/arnika-project/arnika (Go). Ecosystems affected: Go.

How do I fix GHSA-rc6v-5rmx-w5mv?

Update github.com/arnika-project/arnika to 1.0.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rc6v-5rmx-w5mv is resolved across your whole dependency graph.

How do I detect GHSA-rc6v-5rmx-w5mv in my Go dependencies?

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

How do I mitigate GHSA-rc6v-5rmx-w5mv 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.

Is GHSA-rc6v-5rmx-w5mv actively exploited in the wild?

No public exploit code has been indexed for GHSA-rc6v-5rmx-w5mv 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-rc6v-5rmx-w5mv published, and has it been updated?

GHSA-rc6v-5rmx-w5mv was published on May 15, 2026 and was last updated on June 25, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹

🐹 Go

Not in CISA KEV

LOW severity

GHSA-rc6v-5rmx-w5mv — arnika

LOWFix: arnika-project/arnika@efbd980

GHSA-rc6v-5rmx-w5mv is a low-severity (CVSS 2.8) remote code execution vulnerability in github.com/arnika-project/arnika. A fix is available for github.com/arnika-project/arnika — see the affected versions and patch details below.

arnika is affected by medium-severity issues in UDP rotation, PQC handling, and KMS TLS

Also known asGO-2026-5614

Published

May 15, 2026

Updated

Jun 25, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Jun 25, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

🐹github.com/arnika-project/arnika

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

Three medium-severity issues in arnika affecting the UDP key-rotation protocol, PQC key file handling, and KMS TLS client. All require specific preconditions to exploit and do not allow direct code execution or immediate key extraction. A self-contained PoC is attached.

Details

ACK timestamp not validated: udpserver.go:185 udpClient() verifies HMAC and packet type but never checks ackPkt.Timestamp. A MITM can capture one ACK, drop all subsequent DATA packets, and replay the stale ACK indefinitely. Primary advances PSK each rotation, backup stays on key 1, tunnel breaks. No PSK knowledge needed. The server side already has this check, the client does not. Fix: mirror the timestamp check already present on the server side.
Empty PQC key file silently accepted: repositories/pqc.go:29 os.ReadFile follows symlinks. Empty file to base64.Decode("") = []byte{}, nil. HKDF runs on the QKD key alone while arnika logs [OK] HKDF derivation completed for QKD+PQC key. Requires write access to the directory containing PQC_PSK_FILE. Fix: validate decoded key is non-empty before derivation; enforce parent directory permissions in SECURITY.md.
InsecureSkipVerify: true hardcoded: repositories/kms.go:61 KMS HTTP client unconditionally sets InsecureSkipVerify: true, overriding RootCAs. CA_CERTIFICATE is loaded but never consulted (dead code). Requires MITM between arnika and the KMS endpoint, which in typical deployments are co-located. Fix: remove the flag; RootCAs already holds the correct pool when CA_CERTIFICATE is configured.

PoC

See arnika_exploit.tar.gz. PoC shows observable behavior for each attack; the third one (KMS MITM) needs no custom code, any HTTPS proxy with a self-signed cert is enough.

Impact

Issues require network MITM or local directory write access to exploit. No direct key extraction or code execution. Primary impact is tunnel desync and silent security downgrade in hybrid QKD+PQC mode.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/arnika-project/arnika`	all versions	1.0.1`go get github.com/arnika-project/arnika@v1.0.1`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/arnika-project/arnika, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/arnika-project/arnika to 1.0.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rc6v-5rmx-w5mv 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.

Frequently Asked Questions

### Summary Three medium-severity issues in arnika affecting the UDP key-rotation protocol, PQC key file handling, and KMS TLS client. All require specific preconditions to exploit and do not allow direct code execution or immediate key extraction. A self-contained PoC is attached. ### Details 1) ACK timestamp not validated: `udpserver.go:185` `udpClient()` verifies HMAC and packet type but never checks `ackPkt.Timestamp`. A MITM can capture one ACK, drop all subsequent DATA packets, and replay the stale ACK indefinitely. Primary advances PSK each rotation, backup stays on key 1, tunnel break

O3 Security · Impact-Aware SCA

Is GHSA-rc6v-5rmx-w5mv in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works