How severe is GHSA-c48m-x2xw-32rj?

No CVSS score has been assigned to GHSA-c48m-x2xw-32rj yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-c48m-x2xw-32rj?

Affected package information for GHSA-c48m-x2xw-32rj is not yet fully mapped. Check the official advisory links for details.

How do I fix GHSA-c48m-x2xw-32rj?

The records we use list no fixed release for GHSA-c48m-x2xw-32rj. Check the upstream advisory for a patched version, and apply the exposure-reduction steps below in the meantime.

How do I detect GHSA-c48m-x2xw-32rj in my code and dependencies?

Identify every host running the affected component and compare the installed build against the fixed version below — for source-built or distro-packaged software the version string, not a lockfile, is the source of truth (`dpkg -l`, `rpm -q`, or the binary's own `--version`).

How do I mitigate GHSA-c48m-x2xw-32rj if there is no patch (or I can't update yet)?

Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Is GHSA-c48m-x2xw-32rj actively exploited in the wild?

No public exploit code has been indexed for GHSA-c48m-x2xw-32rj 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.

What is the EPSS score for GHSA-c48m-x2xw-32rj?

GHSA-c48m-x2xw-32rj has an EPSS (Exploit Prediction Scoring System) score of 0.5%, placing it in the 39th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-c48m-x2xw-32rj?

GHSA-c48m-x2xw-32rj is classified as Missing Authentication (CWE-306). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-c48m-x2xw-32rj published, and has it been updated?

GHSA-c48m-x2xw-32rj was published on August 6, 2026 and was last updated on October 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

Dinky Unauthenticated System Configuration and…

Exploitation Status

No confirmed exploitation observed yet

CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-c48m-x2xw-32rj.

EPSS Exploitation Probability

via FIRST.org ↗

0.5%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs39th percentile — riskier than 39% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Description

Dinky's SysConfigController.getAll() handler for GET /api/sysConfig/getAll carries a method-level @SaIgnore annotation that short-circuits the class-level @SaCheckLogin, so the Sa-Token interceptor lets the request through with no session or role check. Any remote unauthenticated caller who can reach the Dinky HTTP port (8888 by default) receives the full live system configuration (54 entries on a stock v1.2.5 install) with one parameterless GET. Only one credential field (sys.maven.settings.repositoryPassword) has a desensitization handler wired; the other credential-bearing fields (sys.env.settings.dinkyToken, sys.ldap.settings.userPassword, sys.resource.settings.oss.accessKey and secretKey, and sys.dolphinscheduler.settings.token) return in cleartext. A bare install leaks the shipped defaults, including the hardcoded dinkyToken efda1551-7958-4e0f-80a8-dfd107df3e38 and minioadmin/minioadmin OSS keys; once an operator configures LDAP, object storage, or DolphinScheduler through the Settings Center, those live third-party credentials leak from the same endpoint. Because dinkyToken is the sole gate on the sibling POST /download/uploadFromRsByLocal arbitrary file write, this disclosure defeats token rotation as a mitigation for that vulnerability. Affects Dinky v1.2.5 (the current release, 2025-11-05) and the development branch (dev HEAD 63b5a5a), where the affected code is byte-identical.

Detection & mitigation playbook

Vulnerability

Detect
Identify every host running the affected component and compare the installed build against the fixed version below — for source-built or distro-packaged software the version string, not a lockfile, is the source of truth (`dpkg -l`, `rpm -q`, or the binary's own `--version`).
Remediation status
The records we use list no fixed release for GHSA-c48m-x2xw-32rj. Check the upstream advisory for a patched version, and apply the exposure-reduction steps below in the meantime.
Mitigate without a patch
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

Dinky's SysConfigController.getAll() handler for GET /api/sysConfig/getAll carries a method-level @SaIgnore annotation that short-circuits the class-level @SaCheckLogin, so the Sa-Token interceptor lets the request through with no session or role check. Any remote unauthenticated caller who can reach the Dinky HTTP port (8888 by default) receives the full live system configuration (54 entries on a stock v1.2.5 install) with one parameterless GET. Only one credential field (sys.maven.settings.repositoryPassword) has a desensitization handler wired; the other credential-bearing fields (sys.env.s

O3 Security · Impact-Aware SCA

Is GHSA-c48m-x2xw-32rj in your dependencies?

Find it across your dependency tree, including transitive dependencies.

Scan my dependencies How O3 SCA works

Dinky Unauthenticated System Configuration and Credential Disclosure via GET /api/sysConfig/getAllGHSA-c48m-x2xw-32rj