CVE-2026-55454
Appsmith ≤ 2.1
Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HSummary
CVE-2026-55454 is a critical-severity Exposed Dangerous Method or Function (CWE-749) vulnerability in Appsmith Appsmith. Its CVSS base score is 9.9 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Default Accounts (T1078.001); ranked at the 32th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to AC-3 (Access Enforcement) and AC-6 (Least Privilege) — see the control section below for these in your framework.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-39118
Vulnerability Data
Appsmith is a platform to build admin panels, internal tools, and dashboards. Prior to 2.1, the bundled Caddy reverse-proxy's admin API — which has no authentication by default — is bound on 0.0.0.0:2019 inside the container. While this listener is…
more
not directly published to the host by docker-compose.yml, it is reachable from the Appsmith server process itself or a SSRF vulnerability. An authenticated low-privileged user can therefore drive the SSRF to issue POST /load (or any other admin-API call) against http://0.0.0.0:2019/, fully replacing the live Caddy configuration and taking over the reverse proxy. This vulnerability is fixed in 2.1.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 17 hardening rules · 7 OS baselines
V14.3.2V6.3.2V11.3.1V13.2.3
Mitigating Controls (NIST 800-53 r5) AI
Access enforcement directly stops unauthorized callers from invoking dangerous API methods or functions.
Least privilege restricts which users or processes may reach dangerous methods, limiting exposure.
Baseline configuration directly requires documenting and maintaining secure initial settings instead of insecure defaults.
Configuration settings mandate the most restrictive values be applied at initialization, eliminating reliance on insecure factory defaults.
Least functionality removes or disables non-essential dangerous methods from the exposed interface altogether.
Security engineering principles include explicit requirements for secure defaults during resource initialization and design.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Enforcing least-privilege authorization directly prevents unrestricted dangerous API methods.
Hardened baselines and configuration management directly replace insecure defaults with secure settings.
Secure SDLC practices stop developers from exposing dangerous functions in the first place.
Vulnerability identification processes will surface exposed dangerous methods during assessment.
Pre-acquisition integrity checks can reject products known to ship with insecure defaults.
Logical access controls at the network/environment layer can limit reachability of exposed functions.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect exposed dangerous functions, but does not prevent their initial introduction.
Mandating secure baseline templates and immediate replacement of vendor defaults directly stops systems from being deployed with insecure factory settings that attackers can exploit.
Restricting privileged utility programs reduces exposure of dangerous functions, but does not eliminate the underlying weakness.
Privileged access rights limit who can invoke dangerous methods, but do not address whether the method itself should exist.
Secure development life cycle requires removal or protection of dangerous APIs during design and coding.
Application security requirements can mandate that dangerous methods are not exposed in interfaces.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
Oracle Linux 8 (1 rule)
- V-248823 OL 8 must not have the telnet-server package installed. prevents CWE-1188
RHEL 7 (1 rule)
- V-204627 SNMP community strings on the Red Hat Enterprise Linux operating system must be changed from the default. prevents CWE-1188
Ubuntu 22.04 (3 rules)
- V-260529 Ubuntu 22.04 LTS must be configured so that remote X connections are disabled, unless to fulfill documented and validated mission requirements. prevents CWE-1188, CWE-749
- V-260559 Ubuntu 22.04 LTS must ensure only users who need access to security functions are part of sudo group. prevents CWE-749
- V-260557 Ubuntu 22.04 LTS must be configured to use AppArmor. prevents CWE-749
Ubuntu 24.04 (2 rules)
- V-270708 Ubuntu 24.04 LTS must be configured so that remote X connections are disabled, unless to fulfill documented and validated mission requirements. prevents CWE-1188
- V-270748 Ubuntu 24.04 LTS must ensure only users who need access to security functions are part of sudo group. prevents CWE-749
Windows Server 2016 (1 rule)
- V-224972 Active Directory Group Policy objects must have proper access control permissions. prevents CWE-1188
Windows Server 2019 (1 rule)
- V-205741 Windows Server 2019 Active Directory Group Policy objects must have proper access control permissions. prevents CWE-1188