Backstage
Monthly
Improper validation of MkDocs Markdown extension configuration in Backstage's TechDocs Node package (@backstage/plugin-techdocs-node) lets an authenticated user who can register or modify documentation sources make a TechDocs build read files or fetch URLs outside the documentation boundary, potentially exposing backend-host data or internal network resources (path traversal, CWE-22). Affected versions are those before 1.14.6 on the 1.14 line and before 1.15.4 on the 1.15 line; the impact is changed-scope with high confidentiality loss and no integrity or availability impact, and it applies to deployments where the Backstage backend generates TechDocs from those sources rather than relying on externally sandboxed CI. Exploitation requires an authenticated principal with documentation-source registration or modification rights (PR:L), and no public exploit code has been identified at time of analysis; this is assessed as a credible, patch-worthy issue rather than an emergency, with vendor fixes released in @backstage/plugin-techdocs-node 1.14.6 and 1.15.4 plus pymdown-extensions 10.21.3 or newer.
Path traversal in Backstage's optional @backstage/plugin-scaffolder-backend-module-confluence-to-markdown package (versions before 0.3.25) allows an authenticated user who can execute a template using the confluence:transform:markdown action and control the repository file location to write generated content outside the task workspace, potentially overwriting files writable by the Backstage backend process. The vulnerability is rated CVSS 7.1 with high integrity and low availability impact but no confidentiality impact; exploitation requires the module to be installed and enabled, and the attacker must supply directory-traversal sequences in the repoUrl input. The issue is fixed in version 0.3.25 (Backstage release v1.54.6), and no public exploit has been identified at time of analysis.
Authenticated remote code execution in the @backstage/plugin-techdocs-node package shipped with the Backstage developer portal framework allows a user who can register or influence an SCM-backed documentation source to execute arbitrary code on the TechDocs backend host. The flaw (CWE-502, CVSS 8.8, vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) arises because mapping-style markdown_extensions entries in a committed mkdocs.yml were not sanitized, letting an attacker name Python callables such as subprocess:Popen or os:system that MkDocs then imports and instantiates during documentation generation. Exploitation requires a valid account and an instance that performs server-side TechDocs generation of attacker-controlled sources, so risk is highest where generation runs with backend credentials, filesystem access, or internal network reachability; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV).
Command injection in Backstage's TechDocs build pipeline allows an authenticated user who can register or modify a documentation source to run arbitrary commands inside the TechDocs backend or its build container by supplying a crafted mkdocs.yml. Exploitation requires write access to a catalog entity or docs source that is processed by local or docker-based TechDocs generation, and the impact is confined to resources reachable by the backend or its build container; deployments that only publish externally pre-built documentation are not exposed. The issue is fixed in @backstage/plugin-techdocs-node 1.14.6 and 1.15.4, is rated CVSS 7.7 with high attack complexity, low privileges, and scope change, and there is no public exploit identified at time of analysis.
Remote code execution on TechDocs build hosts affects Backstage deployments running the @backstage/plugin-techdocs-node mkdocs generator prior to 1.14.6 (and 1.15.x prior to 1.15.4). An authenticated user holding the privilege to register or update catalog entities can commit a crafted mkdocs.yml whose markdown_extensions entries point at dangerous Python callables such as subprocess:Popen, os:system, or plantuml_markdown's plantuml_cmd, which mkdocs instantiates and executes while building the docs; the flaw requires authentication and an entity-registration permission rather than anonymous access, and deployments that publish pre-built docs or build in isolated disposable runners have a much smaller blast radius. The upstream fix, which extends MkDocs configuration sanitization to cover nested configuration keys, hyphenated extension names, and theme options, is available in vendor-released versions 1.14.6 and 1.15.4, and no public exploit code tied to this CVE was identified at time of analysis beyond the payload fixtures included in the upstream fix commit.
Arbitrary code execution in Backstage TechDocs documentation builds allows an authenticated user with write access to a repository registered in the Backstage catalog to run commands on the build host by embedding malicious keys in the repository's mkdocs.yml. Both TechDocs build modes configured locally or in a container (techdocs.generator.runIn set to 'local' or 'docker') are vulnerable because the affected @backstage/plugin-techdocs-node package (prior to 1.14.6, and 1.15.0 through 1.15.3) failed to sanitize nested markdown_extensions and theme configuration values before invoking MkDocs. Exploitation is access-gated rather than anonymous: CVSS 3.1 scores this 8.8 with a PR:L vector, EPSS is low at 0.26% (16th percentile), CISA SSVC rates exploitation as none and automatable as no, and no public exploit code has been identified at time of analysis.
Arbitrary code execution on the TechDocs backend host is achievable through a sanitizer bypass in the @backstage/plugin-techdocs-node package prior to versions 1.14.6 and 1.15.4, where crafted MkDocs configuration keys (notably extra_templates) evade the allowlist filter originally added to fix CVE-2026-25153. Exploitation is not anonymous: an attacker must hold write/commit access to a repository onboarded into a TechDocs-enabled Backstage instance (PR:L, authenticated), and must defeat an existing hardened sanitizer (AC:H), after which the malicious configuration executes automatically during documentation generation with no further user interaction (UI:N) and can compromise confidentiality, integrity, and availability of the backend host and, per the S:C scope change, potentially beyond it. No public exploit code has been identified at time of analysis, CISA KEV does not list this issue, SSVC rates exploitation as none and automatable as no, and EPSS is low at 0.27% (18th percentile), making this a genuine but conditional priority rather than a drive-by critical. This is a genuine but conditional priority, not a drive-by critical.
Authenticated users of Backstage Scaffolder can bypass administrator-configured action restrictions in @backstage/plugin-scaffolder-backend by supplying a restricted input value with different letter casing or as a different JSON type (for example a number instead of a string), causing permission checks to fail to match and letting the action execute with the backend integration's credentials. This can grant unauthorized access to repositories and related source-control resources, bounded by the privileges of the integration tokens attached to the affected actions. The issue affects versions before 3.3.1, 3.4.1, 4.0.3, and 4.1.0, and only matters in deployments that actually use input-value-based permission rules; no public exploit code has been identified at time of analysis.
Authenticated Backstage users can retrieve the internal execution data of other users' Scaffolder tasks - notably the SerializedTask secrets field (including __initiatorCredentials) and state.checkpoints - through the scaffolder-backend task API in versions prior to 3.3.1, 3.4.1, 4.0.3 and 4.1.0. Where scaffolder tasks or templates place credentials for an external service into those fields, the disclosure can extend to unauthorized changes in that external system, which is reflected in the assigned CRITICAL 9.6 score (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) and its scope change. Exploitation requires a valid authenticated account with permission to read the target task, and no public exploit has been identified at time of analysis.
Improper task-state validation in the @backstage/plugin-scaffolder-backend plugin (Backstage versions prior to 3.3.1, 3.4.1, 4.0.3 and 4.1.0) allows an authenticated user who holds permission to create and access Scaffolder tasks to race the task-retry path and, under specific timing and deployment conditions, influence files reachable by the Backstage backend process. Where the backend's application files are writable by the service - a non-default configuration - this can compromise the confidentiality, integrity and availability of the backend, which is why the advisory carries a high 8.5 CVSS score with scope change; no public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV) for this issue. Real-world impact is gated by three conditions: the attacker must be authenticated with the Scaffolder permission (PR:L, not anonymous), must win a non-deterministic timing window (AC:H), and must target a deployment whose backend files are writable, so hardened environments with read-only application files are substantially less exposed than the headline score suggests.
Improper URL validation in the @backstage/plugin-catalog-backend package of Backstage prior to 3.5.1, 3.6.2, 3.7.2, 3.8.2 and 3.9.1 lets an authenticated user with catalog-write capability craft catalog entities whose placeholder directives ($text, $json, $yaml) resolve to files in a repository other than the entity's own source repo. Because the placeholder resolver executes with the backend's configured SCM integration credentials, the attacker can read content the resolver is authorized to fetch but that the user should not see, giving a confidentiality impact rated 7.7 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N). Exploitation requires a valid authenticated account plus a deployment where integrations can reach the targeted external resource - the vendor scopes impact to 'certain configurations,' so hardened single-repo or tightly scoped integration setups may not be affected; no public exploit code was identified at time of analysis.
Improper preservation of access restrictions in Backstage's @backstage/backend-defaults package lets an authenticated holder of a restricted external service credential (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L, rated 7.6) escalate privileges by routing requests through plugin-to-plugin delegation: the credential's permission-name or permission-attribute limits (for example action:read) are dropped when a plugin request token is minted on the credential's behalf, so a read-only principal can perform write operations on plugins it should only be able to read. Only deployments that both use @backstage/backend-defaults and configure external service credentials with accessRestrictions are exposed, and exploitation is scoped to plugins reachable through the delegation path. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV); fixed releases are @backstage/backend-defaults 0.16.1 and 0.17.8.
Improper authentication in the Backstage @backstage/plugin-auth-backend-module-oidc-provider package prior to 0.4.20 lets an authenticated user of a configured OIDC identity provider impersonate another catalog identity. Exploitation requires a deployment that resolves sign-in identities by matching the OIDC email claim AND an identity provider that issues email addresses without asserting email_verified=true, in which case the attacker's unverified, self-controlled email can match a victim's catalog identity and inherit that identity's access and permissions (CVSS 3.1 base 8.1, PR:L, no availability impact). No public exploit code has been identified at time of analysis, and the flaw is fixed by omitting the email from the default OIDC profile transform unless the provider explicitly marks it verified.
The Bitbucket pull-request Scaffolder actions in Backstage can be abused by an authenticated user with template-execution rights and influence over the target Bitbucket repository to copy files outside the intended temporary workspace, potentially affecting backend confidentiality, integrity or availability. Deployments running @backstage/plugin-scaffolder-backend-module-bitbucket-cloud before 0.3.10 or @backstage/plugin-scaffolder-backend-module-bitbucket-server before 0.2.25 (Backstage before 1.54.6) are affected; the vendor rates the issue CVSS 9.9 (scope changed, PR:L). No public exploit identified at time of analysis (EPSS 0.33%, CISA SSVC exploitation: none), but vendor-released fixed versions exist and the issue carries an act_now priority.
Improper input validation in the @backstage/plugin-scaffolder-backend-module-sentry scaffolder actions (Backstage 0.3.0 through 0.3.7) lets an authenticated internal Backstage user who is permitted to run the Sentry actions (for example sentry:project:create) supply a caller-controlled apiBaseUrl, causing the Backstage backend to send requests - including the configured Sentry Bearer token - to an attacker-chosen destination. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N, base 8.5) reflects a low-privilege, network-reachable flaw with scope change and high confidentiality impact, since the leaked integration token's usefulness depends on the token's privileges and network reachability. No public exploit code or confirmed active exploitation has been identified at time of analysis, but a vendor advisory, a fix commit, and patched releases exist.
Insufficient audience validation in Backstage's Cloudflare Access auth provider package (@backstage/plugin-auth-backend-module-cloudflare-access-provider 0.1.0 through 0.4.x) lets a user who already holds a valid Cloudflare Access JWT issued for a different Access application inside the same Cloudflare Zero Trust team authenticate to Backstage, because the provider verifies the token signature and team issuer but never checks the token's audience (AUD) claim. Exploitation is conditional: the forged-context token must actually reach the Backstage auth endpoint on a path where Cloudflare Access has not already enforced the Backstage application's own AUD tag upstream, and the attacker must be an authenticated member of the shared Zero Trust team, which is why the assessed vector carries AC:H and PR:L and the resulting rating is a moderate, conditional authentication bypass rather than a top-tier priority. No public exploit code has been identified at time of analysis, and the issue is fixed in plugin version 0.5.0 (shipped with Backstage v1.55.0), where the 'audience' configuration value becomes mandatory.
Server-side request forgery in the Backstage @backstage/plugin-techdocs-node package (0.11.12 through 1.14.6, and 1.15.0 through 1.15.4) lets an authenticated user who controls a TechDocs source repository have documentation builds fetch and publish content from network locations reachable by the build environment. The issue is rated CVSS 7.7 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N), reflecting a confidentiality-only, scope-changing impact that requires repo write access and a build topology where internal endpoints are reachable without token or special-header protections; newer cloud metadata services that require tokens or custom headers are explicitly not directly accessible. Vendor-released patches exist in @backstage/plugin-techdocs-node 1.14.7 and 1.15.5 (and in Backstage releases v1.50.6, v1.54.8, v1.55.0); no public exploit identified at time of analysis.
Authenticated users who can register or modify a TechDocs documentation source can achieve code execution inside the Backstage TechDocs backend or its build container by supplying a crafted mkdocs.yml, because @backstage/plugin-techdocs-node fails to strip unsafe Python YAML tags, markdown_extensions names and their configuration, theme options, and extra_templates values before the file reaches the Python documentation generator. The flaw affects the techdocs-node plugin before 1.14.6 and the 1.15.0 through 1.15.3 range, and the vendor has released fixes in 1.14.6 and 1.15.4. Authentication is mandatory per the CVSS vector (PR:L), no public exploit code or confirmed active exploitation was identified at time of analysis, and the blast radius is limited to the files, credentials, and network reach of the TechDocs backend or build container rather than the wider Backstage host.
Arbitrary Python code execution in Backstage's @backstage/plugin-techdocs-node (versions < 1.13.11 and = 1.14.0) lets a contributor who can add or edit a repository's mkdocs.yml inject a malicious MkDocs `hooks` directive that runs on the TechDocs build server whenever TechDocs is configured with `runIn: local`. The flaw also affects documentation built in CI/CD via @techdocs/cli, which bundles the same package. EPSS is very low (0.02%, 6th percentile) and there is no public exploit identified at time of analysis, but the CVSS of 8.8 reflects full host compromise of the build environment.
Catalog ingestion policy bypass in @backstage/plugin-catalog-backend lets an authenticated user holding the catalog.location.create permission register a URL whose raw string matches a trusted catalog.rules prefix (for example https://ghe.example.com/trusted/**) while the URL reader canonicalizes it to a location outside that prefix, so entity content from an untrusted source is ingested as if it came from a trusted one. Versions before 3.9.2 and 4.0.0 through 4.0.1 are affected, fixed in 3.9.2 (Backstage 1.54.10) and 4.0.2 (Backstage 1.56.1). Impact is scoped to the operator-configured ingestion policy boundary, downstream effects depend on deployment configuration, and no public exploit identified at time of analysis.
Improper access control in the @backstage/backend-defaults package of the Backstage developer portal framework (versions prior to 0.17.8, shipped in Backstage releases before v1.54.6) allows an authenticated user to invoke backend actions that an operator had explicitly excluded through backend.actions configuration. The excluded actions are filtered out when actions are listed, but the invocation path never re-applied those filters, so a caller who knows or guesses an action ID can still trigger it; per-action permissions and downstream authorization remain enforced, which caps the impact at a low-integrity exposure (CVSS 4.3, C:N/I:L/A:N). There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV), and the issue only matters in deployments that actually configured action exclusions. Fixed in @backstage/backend-defaults 0.17.8.
Improper entity validation in the deprecated Kubernetes services endpoint of @backstage/plugin-kubernetes-backend lets an authenticated Backstage user who already holds Kubernetes read permissions retrieve Kubernetes object metadata beyond their intended scope by submitting crafted entity data in the request body. The vulnerable handler trusted the caller-supplied entity reference instead of resolving it against the Backstage catalog, so the request was processed against an entity the user was not authorized for; the fix (0.21.8) parses the entity reference and performs a catalog lookup, returning 403 when no matching entity exists. Exposure is limited to read-only Kubernetes object metadata across configured clusters with no integrity or availability impact, and no public exploit code has been identified at time of analysis; exploitation is constrained to the legacy deprecated services endpoint and requires a crafted request that evades validation (AC:H).
Permission-filtered search in Backstage deployments that use an Elasticsearch or OpenSearch backend can return documents that a DENY policy should have withheld, because an empty list of permitted document types causes the engine to issue an unfiltered query across all indices instead of returning zero results. Only authenticated Backstage users (CVSS PR:L) are positioned to trigger this, and only when permission.enabled is set to true, the search backend is Elasticsearch/OpenSearch rather than the default in-memory engine, and the user is actually governed by a DENY policy for one or more search document types; the impact is limited to confidentiality (C:L) with no integrity or availability effect. The vendor has released fixes in @backstage/plugin-search-backend 2.1.6 and @backstage/plugin-search-backend-module-elasticsearch 1.8.7 (Backstage release v1.54.1), and there is no public exploit identified at time of analysis. Consistent with our independent assessment, this is a genuine but low-urgency information-disclosure issue rather than a high-priority emergency.
Sensitive information disclosure in the @backstage/plugin-kubernetes-backend package before version 0.21.9 allows an authenticated Backstage user who holds the standard Kubernetes resource read permission to retrieve Kubernetes Secret values that the plugin is designed to mask. The flaw is specifically reachable through the custom resources query path, where both the `data` and `stringData` fields of Secrets were returned unmasked, potentially exposing credentials and other confidential material held in connected clusters. Exposure is bounded by the Backstage service account's RBAC scope and by the targeted catalog entity's namespace and label selector, so deployments whose cluster credentials cannot read those resources are unaffected; there is no public exploit code identified at time of analysis and the issue carries a moderate CVSS of 5.0.
Path traversal in the Backstage Confluence-to-Markdown scaffolder module can let an authenticated Backstage user who runs a template with attacker-influenced Confluence content cause file writes outside the intended image directory, affecting integrity and potentially availability of the scaffolder workspace. The vulnerable package is @backstage/plugin-scaffolder-backend-module-confluence-to-markdown before 0.3.25; exploitation requires the optional module to be deployed and wired into a template, plus an attacker able to create or modify Confluence attachment metadata. There is no public exploit identified at time of analysis, and the issue is fixed in version 0.3.25 and Backstage release v1.54.6.
Filesystem path traversal in the Backstage TechDocs local publisher (@backstage/plugin-techdocs-node) can expose host files - such as /etc/passwd - to authenticated users of the documentation serving endpoint when the backend is configured with techdocs.publisher.type: 'local'. Exploitation requires a documentation source tree that already contains a symbolic link pointing outside the intended output directory, a precondition the vendor states does not arise through normal MkDocs operation, plus an authenticated user able to reach the endpoint (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.3, confidentiality-only impact). Cloud publishers (S3, GCS, Azure Blob Storage) are explicitly not affected, and no public exploit code has been identified at time of analysis; the issue is fixed in @backstage/plugin-techdocs-node 1.15.4.
Arbitrary file read in the Backstage TechDocs node plugin (@backstage/plugin-techdocs-node) prior to 1.15.4 allows an authenticated user who can register documentation sources to escape the intended documentation boundary. Because TechDocs only validated symlinks inside the docs_dir, an attacker-controlled source tree containing a symlink that resolves outside the tree (e.g. to /etc/passwd) plus an MkDocs snippets include directive ('--8<--') could pull that out-of-bounds file into the generated documentation, exposing anything readable by the build process. Exploitation requires authenticated access (PR:L), a crafted symlink/snippet chain (AC:H), and a deployment that builds docs from user-registerable sources; impact is confidentiality-only (C:H/I:N/A:N, CVSS 5.3), and no public exploit was identified at time of analysis.
Improper input validation in the Backstage Scaffolder backend (@backstage/plugin-scaffolder-backend) before version 4.1.0 allows an authenticated user with permission to create and read scaffolder tasks to influence how the task list endpoint orders results, enabling inference of confidential task data such as secrets. Exploitation is not straightforward: the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N (5.3 Medium), and the advisory requires four stacked preconditions - the target task's secrets must still be retained (not purged), the attacker must be able to see the target task, the attacker must already know the structure of the secret being inferred, and the attack depends on many repeated list requests - so the practical outcome is partial inference rather than guaranteed full secret disclosure. There is no public exploit identified at time of analysis, and no KEV listing; the issue is fixed in @backstage/plugin-scaffolder-backend 4.1.0 (Backstage release v1.54.6).
Sensitive-value disclosure in the @backstage/plugin-scaffolder-backend package prior to 4.1.0 lets an authenticated user who can create and read scaffolder tasks observe secret values in task logs and error messages. Exposure is conditional: it requires a deployment using the scaffolder permission framework with restrictive action permissions that actually deny an action, plus an affected template that passes a task secret, an environment secret, or a secret-derived 'each' key as input to that denied action. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV); risk is moderate and highly configuration-dependent because default deployments without action-level denials and templates that do not route secrets through denied actions are unaffected.
Information disclosure in the Backstage Scaffolder backend (@backstage/plugin-scaffolder-backend) prior to 4.1.0 allows an authenticated user who can run or view a Scaffolder task to recover backend-managed credentials from persisted task failure events. When a template injects secrets (for example via ${{ secrets.secret }}) into an action or checkpoint and that step fails, the raw secret values were written into the failure reason, error name, and error message without passing through the configured log redaction, and nested error objects were attached to the surfaced error. Exploitation requires a valid Backstage account (PR:L) and a narrow combination of template content and failure path (AC:H), so this is a genuine but moderate-priority CWE-532 leak rather than a broadly weaponizable flaw; no public exploit has been identified at time of analysis, and installations on @backstage/plugin-scaffolder-backend 4.1.0 or Backstage v1.54.6 and later are not affected.
Secret-derived values used during Scaffolder template iteration in Backstage can leak into task logs, exposing configured scaffolder.defaultEnvironment.secrets to anyone who can read those logs. Affected deployments run the @backstage/plugin-scaffolder-backend package prior to version 4.1.0, and exploitation requires a privileged, authenticated template author (PR:H in the CVSS vector) plus a deployment that has populated sensitive values in scaffolder.defaultEnvironment.secrets. The flaw only manifests when secret-derived values pass through a transforming Nunjucks filter inside an 'each' loop, since untransformed secrets were already redacted; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV). Realistic risk is moderate given the layered prerequisites, though the confidentiality impact for exposed credentials is high.
Inconsistent property-permission matching in the @backstage/plugin-catalog-backend package (Backstage releases prior to the fix) allows an authenticated user to receive catalog entity data that policy authors intended to restrict, because value-based catalog permission conditions evaluate keys and values inconsistently. Exposure is limited to deployments that use these value-based property conditions as a confidentiality boundary; installations without such value-based restrictions are not affected, and no public exploit has been identified at time of analysis. The issue is rated CVSS 4.3 (low severity, information disclosure only) and is fixed in @backstage/plugin-catalog-backend 3.9.1, shipped with Backstage release v1.54.6.
Backstage's catalog backend (the @backstage/plugin-catalog-backend package) prior to 3.9.1 enforces its allowedLocationTypes restriction inconsistently, letting a disallowed location type be processed when it is inherited from the parent/origin location rather than declared directly. An authenticated user who can register or influence a Location entity in a deployment that has configured an allowedLocationTypes list can therefore trigger the backend to resolve a location type it was supposed to reject, potentially reading files on the backend host. This is a low-severity issue: it requires non-default configuration plus authenticated access and a specific inheritance edge case, and no public exploit code has been identified at time of analysis; the fix is in @backstage/plugin-catalog-backend 3.9.1 (Backstage release v1.54.6).
Content injection in Backstage's cloud storage URL readers (the @backstage/backend-defaults package before 0.17.8) allows an attacker who holds write access to a configured AWS S3 bucket, AWS CodeCommit repository, or Azure Blob Storage container to craft object names containing path traversal segments so that an ingested object can collide with a protected file in the reader's output directory, overwriting or injecting content in certain deployment configurations. The issue is a CWE-22 improper-limitation-of-pathname flaw with an integrity-only impact, scored CVSS 4.4 (AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N), meaning exploitation demands high privileges (bucket write access) and a non-trivial collision condition, while confidentiality and availability are unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and a vendor patch is available in @backstage/backend-defaults 0.17.8 (Backstage v1.54.6).
Backstage deployments prior to 1.54.6 that use Azure Blob Storage or AWS S3 catalog sources can be induced to read catalog descriptors from outside the configured storage boundary - an object-storage path traversal in the cloud storage catalog providers and cloud URL readers. Exploitation requires an authenticated principal with high privileges (CVSS PR:H) who already has permission to create or rename objects in the trusted catalog bucket or container, and who then crafts object names containing dot-path segments (including encoded forms such as %2e%2e or backslash-delimited variants) to escape the intended prefix; the read is limited to locations reachable with the backend's own configured storage credentials, and impact is confidentiality-only (CVSS 3.0, AV:N/AC:H/PR:H/S:C/C:L/I:N/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; a vendor-released patch is available in 1.54.6.
Improper input validation in Backstage's @backstage/plugin-proxy-backend before 0.6.17 allows an authenticated user to craft a request URL containing path traversal sequences that the proxy forwards to a path outside the configured base path on an already-configured upstream target server. The flaw is bounded: the attacker must already hold an authenticated Backstage session (CVSS vector PR:L, unless an endpoint is deliberately configured with 'dangerously-allow-unauthenticated'), and only hosts that are already registered as proxy endpoints can be reached, so the escape is a redirect within an already-trusted target rather than a route to arbitrary internal systems. There is no indication of confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; the issue is addressed by vendor-released fixes in @backstage/plugin-proxy-backend 0.6.17 and Backstage release v1.54.6.
Improper input validation in the @backstage/plugin-techdocs-backend static content router (versions prior to 2.2.4) lets an authenticated Backstage user reach TechDocs static files outside the entity they are authorized to view when the Azure Blob Storage publisher provider is configured and entity-level permissions are enabled, resulting in high-confidentiality information disclosure. The flaw is a path traversal (CWE-22) reachable over the network by a low-privileged account, rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N); Azure-Blob-Storage-only scope and the required authenticated session keep realistic risk moderate. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor-released fix is @backstage/plugin-techdocs-backend 2.2.4, published in the Backstage monorepo release v1.54.6.
Authenticated users of Backstage TechDocs can bypass entity-scoped authorization and read documentation belonging to other entities by requesting a crafted /static/docs/... URL containing percent-encoded parent-directory (%2e%2e) segments. The issue is confined to deployments that combine the external TechDocs builder with an external storage provider (S3, GCS, etc.) and have the Backstage permission framework enabled; setups without the permission framework are unaffected because TechDocs content is intentionally readable by all authenticated users, and the default local builder/storage path is not exposed. Exploitation requires an authenticated account that already has access to at least one TechDocs site (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, 6.5), exposure is therefore limited to confidentiality of docs across entity boundaries, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Information disclosure in the Backstage Kubernetes backend plugin (@backstage/plugin-kubernetes-backend) before 0.21.10 allows an authenticated catalog contributor who can create or modify kubernetes-cluster Resource entities to steer cluster discovery into an unsupported authentication mode, causing the backend to answer Kubernetes API requests using its own local in-cluster service-account identity rather than a catalog-supplied credential. The disclosure is bounded strictly by what that pod service account is already permitted to read via RBAC, and the leaked credential is used only against the local in-cluster API endpoint and is never transmitted to the catalog-supplied endpoint; exploitation requires a non-default catalog cluster discovery deployment, the relevant endpoint permissions, and over-privileged pod RBAC, which is why the assessed severity is low. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in 0.21.10 (shipped in the Backstage release v1.54.6).
Improper authorization in Backstage's GitLab organization discovery plugin (@backstage/plugin-catalog-backend-module-gitlab) before 0.8.7 causes catalog user-creation events to be applied for GitLab accounts that are not members of the configured group, admitting an unintended catalog identity into the software catalog. Deployments that enable GitLab organization event ingestion and treat the scoped set of ingested catalog users as an access or sign-in boundary may consequently grant an attacker the permissions of a standard authenticated user, consistent with the assessed CVSS 3.1 vector 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), which confirms an authenticated precondition rather than unauthenticated exploitation. The vulnerable org-ingestion/events path is an optional, non-default configuration and no public exploit identified at time of analysis, so this is a moderate-severity authorization hygiene issue rather than an urgent, remotely exploitable bug.
An authenticated Backstage user who can run scaffolder templates can invoke built-in source-control actions (GitHub, GitLab, Azure DevOps, Bitbucket Cloud, Bitbucket Server) without supplying a personal SCM token, causing those actions to fall back to shared integration credentials and perform repository operations with broader privileges than the invoking user holds. The flaw affects deployments on Backstage versions prior to 1.54.6 that have SCM integration credentials configured; custom actions and SCM readers that do not accept a user-token input are unaffected. Exploitation requires the PR:L (authenticated) precondition and offers limited confidentiality and integrity impact with scope change, and no public exploit code has been identified at time of analysis.
Incorrect authorization in the Backstage scaffolder backend (@backstage/plugin-scaffolder-backend) prior to 4.1.0 lets an authenticated user with a valid portal account list scaffolder task metadata that the deployment's permission policy intended to restrict, yielding low-impact information disclosure (CVSS 3.1 base 4.3, PR:L - authentication requirements confirmed by the vector, which contains PR:L). Exposure is confined to task metadata because stored task secrets are not part of the affected response, and deployments that do not enforce a restrictive task visibility policy have essentially nothing to leak. No public exploit code was identified at time of analysis and the issue is not listed in CISA KEV; a vendor-released patch is available in version 4.1.0.
Improper authentication in the Backstage @backstage/plugin-auth-node package (versions 0.3.0 through 0.6.14 and 0.7.x before 0.7.5) lets an already-admitted identity-provider user assume another catalog user's identity and inherit its access and permissions. The flaw is conditional and rated CVSS 6.8 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N): it only triggers when a deployment uses an email-based sign-in resolver that derives catalog identity from the selected profile email AND that email carries an explicit negative verification flag (profile email verified:false, a matching raw provider email_verified:false, or an ID-token-only email with email_verified:false) - an absent email_verified claim alone is not affected. Vendor-released patches exist in 0.6.15 and 0.7.5 (Backstage releases v1.49.7 and v1.54.7), and no public exploit or confirmed active exploitation was identified at time of analysis.
Inconsistent repository filtering in Backstage's Bitbucket Server catalog backend module allows an authenticated Bitbucket Server user to inject catalog locations for repositories that the provider's configured filters are supposed to exclude. Only deployments of @backstage/plugin-catalog-backend-module-bitbucket-server (0.4.0 up to but not including 0.5.15) that use event-driven catalog updates AND configure projectKey, repoSlug, or skipArchivedRepos filters are affected; the attacker must have push access to a filtered-out repository that the Backstage integration credentials can still read. Impact is limited to unauthorized additions to the software catalog (integrity, not confidentiality or availability), no public exploit code has been identified at time of analysis, and exploitation requires valid Bitbucket Server authentication (PR:L) - so this is a genuine but moderate-priority authorization flaw rather than an emergency.
Inconsistent credential enforcement in the @backstage/plugin-proxy-backend package (versions 0.5.0 through 0.6.17) lets unauthenticated callers reach nested proxy upstreams that were explicitly configured to require credentials. When an operator defines an overlapping parent proxy path with credentials set to 'dangerously-allow-unauthenticated' and a nested child path under it with credentials set to 'require', the permissive parent exemption is applied to requests matched by the nested route, so the request is forwarded to the protected upstream and may be sent with static upstream credentials configured for that proxy. The CVSS vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) marks this as unauthenticated but high-complexity because exploitation depends on a specific overlapping proxy configuration rather than default settings; no public exploit code has been identified and the issue is not confirmed actively exploited (no CISA KEV listing).
OAuth authorization code theft in @backstage/plugin-auth-backend prior to 0.29.2 is possible when experimental dynamic client registration or CIMD features are enabled and configured with wildcard-hostname or protocol-less redirect URI allowlist patterns. Full-string glob matching allows a crafted attacker-controlled URI embedding a trusted hostname suffix in its path component to pass the allowlist, delivering authorization codes to the attacker after a victim completes an OAuth flow. No public exploit has been identified and this CVE does not appear in the CISA KEV catalog; real-world impact is sharply bounded by the experimental, disabled-by-default nature of the affected features.
### Impact A Server-Side Request Forgery (SSRF) vulnerability exists in `@backstage/plugin-auth-backend` when `auth.experimentalClientIdMetadataDocuments.enabled` is set to `true`. The CIMD metadata fetch validates the initial `client_id` hostname against private IP ranges but does not apply the same validation after HTTP redirects. The practical impact is limited. The attacker cannot read the response body from the internal request, cannot control request headers or method, and the feature must be explicitly enabled via an experimental flag that is off by default. Deployments that restrict `allowedClientIdPatterns` to specific trusted domains are not affected. ### Patches Patched in `@backstage/plugin-auth-backend` version `0.27.1`. The fix disables HTTP redirect following when fetching CIMD metadata documents. ### Workarounds Disable the experimental CIMD feature by removing or setting `auth.experimentalClientIdMetadataDocuments.enabled` to `false` in your app-config. This is the default configuration. Alternatively, restrict `allowedClientIdPatterns` to specific trusted domains rather than using the default wildcard pattern. ### References - [IETF Client ID Metadata Document draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) - [MCP Authorization Specification - Client ID Metadata Documents](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#client-id-metadata-documents)
Backstage TechDocs plugin versions prior to 1.13.11 and 1.14.1 contain a path traversal vulnerability that allows authenticated attackers to read arbitrary files from the host filesystem when the local generator is enabled. The vulnerability stems from insufficient symlink validation during the documentation build process, enabling attackers to embed sensitive file contents into generated HTML accessible to documentation viewers. Organizations using `techdocs.generator.runIn: local` with untrusted documentation sources are at risk until patching to the fixed versions.
Backstage is an open framework for building developer portals. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Backstage is an open framework for building developer portals. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Backstage is an open framework for building developer portals. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
A flaw was found in the Red Hat Developer Hub (RHDH). Rated medium severity (CVSS 5.7), this vulnerability is remotely exploitable, low attack complexity.
Backstage is an open platform for building developer portals. Rated critical severity (CVSS 9.9), this vulnerability is remotely exploitable, low attack complexity. This Code Injection vulnerability could allow attackers to inject and execute arbitrary code within the application.
@backstage/plugin-scaffolder-backend is the backend for the default Backstage software templates. Rated high severity (CVSS 8.5), this vulnerability is remotely exploitable, low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.
Backstage is an open platform for building developer portals. Rated medium severity (CVSS 4.9), this vulnerability is remotely exploitable, low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.
Backstage is an open platform for building developer portals, and techdocs-common contains common functionalities for Backstage's TechDocs. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.
Improper validation of MkDocs Markdown extension configuration in Backstage's TechDocs Node package (@backstage/plugin-techdocs-node) lets an authenticated user who can register or modify documentation sources make a TechDocs build read files or fetch URLs outside the documentation boundary, potentially exposing backend-host data or internal network resources (path traversal, CWE-22). Affected versions are those before 1.14.6 on the 1.14 line and before 1.15.4 on the 1.15 line; the impact is changed-scope with high confidentiality loss and no integrity or availability impact, and it applies to deployments where the Backstage backend generates TechDocs from those sources rather than relying on externally sandboxed CI. Exploitation requires an authenticated principal with documentation-source registration or modification rights (PR:L), and no public exploit code has been identified at time of analysis; this is assessed as a credible, patch-worthy issue rather than an emergency, with vendor fixes released in @backstage/plugin-techdocs-node 1.14.6 and 1.15.4 plus pymdown-extensions 10.21.3 or newer.
Path traversal in Backstage's optional @backstage/plugin-scaffolder-backend-module-confluence-to-markdown package (versions before 0.3.25) allows an authenticated user who can execute a template using the confluence:transform:markdown action and control the repository file location to write generated content outside the task workspace, potentially overwriting files writable by the Backstage backend process. The vulnerability is rated CVSS 7.1 with high integrity and low availability impact but no confidentiality impact; exploitation requires the module to be installed and enabled, and the attacker must supply directory-traversal sequences in the repoUrl input. The issue is fixed in version 0.3.25 (Backstage release v1.54.6), and no public exploit has been identified at time of analysis.
Authenticated remote code execution in the @backstage/plugin-techdocs-node package shipped with the Backstage developer portal framework allows a user who can register or influence an SCM-backed documentation source to execute arbitrary code on the TechDocs backend host. The flaw (CWE-502, CVSS 8.8, vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) arises because mapping-style markdown_extensions entries in a committed mkdocs.yml were not sanitized, letting an attacker name Python callables such as subprocess:Popen or os:system that MkDocs then imports and instantiates during documentation generation. Exploitation requires a valid account and an instance that performs server-side TechDocs generation of attacker-controlled sources, so risk is highest where generation runs with backend credentials, filesystem access, or internal network reachability; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV).
Command injection in Backstage's TechDocs build pipeline allows an authenticated user who can register or modify a documentation source to run arbitrary commands inside the TechDocs backend or its build container by supplying a crafted mkdocs.yml. Exploitation requires write access to a catalog entity or docs source that is processed by local or docker-based TechDocs generation, and the impact is confined to resources reachable by the backend or its build container; deployments that only publish externally pre-built documentation are not exposed. The issue is fixed in @backstage/plugin-techdocs-node 1.14.6 and 1.15.4, is rated CVSS 7.7 with high attack complexity, low privileges, and scope change, and there is no public exploit identified at time of analysis.
Remote code execution on TechDocs build hosts affects Backstage deployments running the @backstage/plugin-techdocs-node mkdocs generator prior to 1.14.6 (and 1.15.x prior to 1.15.4). An authenticated user holding the privilege to register or update catalog entities can commit a crafted mkdocs.yml whose markdown_extensions entries point at dangerous Python callables such as subprocess:Popen, os:system, or plantuml_markdown's plantuml_cmd, which mkdocs instantiates and executes while building the docs; the flaw requires authentication and an entity-registration permission rather than anonymous access, and deployments that publish pre-built docs or build in isolated disposable runners have a much smaller blast radius. The upstream fix, which extends MkDocs configuration sanitization to cover nested configuration keys, hyphenated extension names, and theme options, is available in vendor-released versions 1.14.6 and 1.15.4, and no public exploit code tied to this CVE was identified at time of analysis beyond the payload fixtures included in the upstream fix commit.
Arbitrary code execution in Backstage TechDocs documentation builds allows an authenticated user with write access to a repository registered in the Backstage catalog to run commands on the build host by embedding malicious keys in the repository's mkdocs.yml. Both TechDocs build modes configured locally or in a container (techdocs.generator.runIn set to 'local' or 'docker') are vulnerable because the affected @backstage/plugin-techdocs-node package (prior to 1.14.6, and 1.15.0 through 1.15.3) failed to sanitize nested markdown_extensions and theme configuration values before invoking MkDocs. Exploitation is access-gated rather than anonymous: CVSS 3.1 scores this 8.8 with a PR:L vector, EPSS is low at 0.26% (16th percentile), CISA SSVC rates exploitation as none and automatable as no, and no public exploit code has been identified at time of analysis.
Arbitrary code execution on the TechDocs backend host is achievable through a sanitizer bypass in the @backstage/plugin-techdocs-node package prior to versions 1.14.6 and 1.15.4, where crafted MkDocs configuration keys (notably extra_templates) evade the allowlist filter originally added to fix CVE-2026-25153. Exploitation is not anonymous: an attacker must hold write/commit access to a repository onboarded into a TechDocs-enabled Backstage instance (PR:L, authenticated), and must defeat an existing hardened sanitizer (AC:H), after which the malicious configuration executes automatically during documentation generation with no further user interaction (UI:N) and can compromise confidentiality, integrity, and availability of the backend host and, per the S:C scope change, potentially beyond it. No public exploit code has been identified at time of analysis, CISA KEV does not list this issue, SSVC rates exploitation as none and automatable as no, and EPSS is low at 0.27% (18th percentile), making this a genuine but conditional priority rather than a drive-by critical. This is a genuine but conditional priority, not a drive-by critical.
Authenticated users of Backstage Scaffolder can bypass administrator-configured action restrictions in @backstage/plugin-scaffolder-backend by supplying a restricted input value with different letter casing or as a different JSON type (for example a number instead of a string), causing permission checks to fail to match and letting the action execute with the backend integration's credentials. This can grant unauthorized access to repositories and related source-control resources, bounded by the privileges of the integration tokens attached to the affected actions. The issue affects versions before 3.3.1, 3.4.1, 4.0.3, and 4.1.0, and only matters in deployments that actually use input-value-based permission rules; no public exploit code has been identified at time of analysis.
Authenticated Backstage users can retrieve the internal execution data of other users' Scaffolder tasks - notably the SerializedTask secrets field (including __initiatorCredentials) and state.checkpoints - through the scaffolder-backend task API in versions prior to 3.3.1, 3.4.1, 4.0.3 and 4.1.0. Where scaffolder tasks or templates place credentials for an external service into those fields, the disclosure can extend to unauthorized changes in that external system, which is reflected in the assigned CRITICAL 9.6 score (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N) and its scope change. Exploitation requires a valid authenticated account with permission to read the target task, and no public exploit has been identified at time of analysis.
Improper task-state validation in the @backstage/plugin-scaffolder-backend plugin (Backstage versions prior to 3.3.1, 3.4.1, 4.0.3 and 4.1.0) allows an authenticated user who holds permission to create and access Scaffolder tasks to race the task-retry path and, under specific timing and deployment conditions, influence files reachable by the Backstage backend process. Where the backend's application files are writable by the service - a non-default configuration - this can compromise the confidentiality, integrity and availability of the backend, which is why the advisory carries a high 8.5 CVSS score with scope change; no public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV) for this issue. Real-world impact is gated by three conditions: the attacker must be authenticated with the Scaffolder permission (PR:L, not anonymous), must win a non-deterministic timing window (AC:H), and must target a deployment whose backend files are writable, so hardened environments with read-only application files are substantially less exposed than the headline score suggests.
Improper URL validation in the @backstage/plugin-catalog-backend package of Backstage prior to 3.5.1, 3.6.2, 3.7.2, 3.8.2 and 3.9.1 lets an authenticated user with catalog-write capability craft catalog entities whose placeholder directives ($text, $json, $yaml) resolve to files in a repository other than the entity's own source repo. Because the placeholder resolver executes with the backend's configured SCM integration credentials, the attacker can read content the resolver is authorized to fetch but that the user should not see, giving a confidentiality impact rated 7.7 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N). Exploitation requires a valid authenticated account plus a deployment where integrations can reach the targeted external resource - the vendor scopes impact to 'certain configurations,' so hardened single-repo or tightly scoped integration setups may not be affected; no public exploit code was identified at time of analysis.
Improper preservation of access restrictions in Backstage's @backstage/backend-defaults package lets an authenticated holder of a restricted external service credential (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L, rated 7.6) escalate privileges by routing requests through plugin-to-plugin delegation: the credential's permission-name or permission-attribute limits (for example action:read) are dropped when a plugin request token is minted on the credential's behalf, so a read-only principal can perform write operations on plugins it should only be able to read. Only deployments that both use @backstage/backend-defaults and configure external service credentials with accessRestrictions are exposed, and exploitation is scoped to plugins reachable through the delegation path. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV); fixed releases are @backstage/backend-defaults 0.16.1 and 0.17.8.
Improper authentication in the Backstage @backstage/plugin-auth-backend-module-oidc-provider package prior to 0.4.20 lets an authenticated user of a configured OIDC identity provider impersonate another catalog identity. Exploitation requires a deployment that resolves sign-in identities by matching the OIDC email claim AND an identity provider that issues email addresses without asserting email_verified=true, in which case the attacker's unverified, self-controlled email can match a victim's catalog identity and inherit that identity's access and permissions (CVSS 3.1 base 8.1, PR:L, no availability impact). No public exploit code has been identified at time of analysis, and the flaw is fixed by omitting the email from the default OIDC profile transform unless the provider explicitly marks it verified.
The Bitbucket pull-request Scaffolder actions in Backstage can be abused by an authenticated user with template-execution rights and influence over the target Bitbucket repository to copy files outside the intended temporary workspace, potentially affecting backend confidentiality, integrity or availability. Deployments running @backstage/plugin-scaffolder-backend-module-bitbucket-cloud before 0.3.10 or @backstage/plugin-scaffolder-backend-module-bitbucket-server before 0.2.25 (Backstage before 1.54.6) are affected; the vendor rates the issue CVSS 9.9 (scope changed, PR:L). No public exploit identified at time of analysis (EPSS 0.33%, CISA SSVC exploitation: none), but vendor-released fixed versions exist and the issue carries an act_now priority.
Improper input validation in the @backstage/plugin-scaffolder-backend-module-sentry scaffolder actions (Backstage 0.3.0 through 0.3.7) lets an authenticated internal Backstage user who is permitted to run the Sentry actions (for example sentry:project:create) supply a caller-controlled apiBaseUrl, causing the Backstage backend to send requests - including the configured Sentry Bearer token - to an attacker-chosen destination. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N, base 8.5) reflects a low-privilege, network-reachable flaw with scope change and high confidentiality impact, since the leaked integration token's usefulness depends on the token's privileges and network reachability. No public exploit code or confirmed active exploitation has been identified at time of analysis, but a vendor advisory, a fix commit, and patched releases exist.
Insufficient audience validation in Backstage's Cloudflare Access auth provider package (@backstage/plugin-auth-backend-module-cloudflare-access-provider 0.1.0 through 0.4.x) lets a user who already holds a valid Cloudflare Access JWT issued for a different Access application inside the same Cloudflare Zero Trust team authenticate to Backstage, because the provider verifies the token signature and team issuer but never checks the token's audience (AUD) claim. Exploitation is conditional: the forged-context token must actually reach the Backstage auth endpoint on a path where Cloudflare Access has not already enforced the Backstage application's own AUD tag upstream, and the attacker must be an authenticated member of the shared Zero Trust team, which is why the assessed vector carries AC:H and PR:L and the resulting rating is a moderate, conditional authentication bypass rather than a top-tier priority. No public exploit code has been identified at time of analysis, and the issue is fixed in plugin version 0.5.0 (shipped with Backstage v1.55.0), where the 'audience' configuration value becomes mandatory.
Server-side request forgery in the Backstage @backstage/plugin-techdocs-node package (0.11.12 through 1.14.6, and 1.15.0 through 1.15.4) lets an authenticated user who controls a TechDocs source repository have documentation builds fetch and publish content from network locations reachable by the build environment. The issue is rated CVSS 7.7 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N), reflecting a confidentiality-only, scope-changing impact that requires repo write access and a build topology where internal endpoints are reachable without token or special-header protections; newer cloud metadata services that require tokens or custom headers are explicitly not directly accessible. Vendor-released patches exist in @backstage/plugin-techdocs-node 1.14.7 and 1.15.5 (and in Backstage releases v1.50.6, v1.54.8, v1.55.0); no public exploit identified at time of analysis.
Authenticated users who can register or modify a TechDocs documentation source can achieve code execution inside the Backstage TechDocs backend or its build container by supplying a crafted mkdocs.yml, because @backstage/plugin-techdocs-node fails to strip unsafe Python YAML tags, markdown_extensions names and their configuration, theme options, and extra_templates values before the file reaches the Python documentation generator. The flaw affects the techdocs-node plugin before 1.14.6 and the 1.15.0 through 1.15.3 range, and the vendor has released fixes in 1.14.6 and 1.15.4. Authentication is mandatory per the CVSS vector (PR:L), no public exploit code or confirmed active exploitation was identified at time of analysis, and the blast radius is limited to the files, credentials, and network reach of the TechDocs backend or build container rather than the wider Backstage host.
Arbitrary Python code execution in Backstage's @backstage/plugin-techdocs-node (versions < 1.13.11 and = 1.14.0) lets a contributor who can add or edit a repository's mkdocs.yml inject a malicious MkDocs `hooks` directive that runs on the TechDocs build server whenever TechDocs is configured with `runIn: local`. The flaw also affects documentation built in CI/CD via @techdocs/cli, which bundles the same package. EPSS is very low (0.02%, 6th percentile) and there is no public exploit identified at time of analysis, but the CVSS of 8.8 reflects full host compromise of the build environment.
Catalog ingestion policy bypass in @backstage/plugin-catalog-backend lets an authenticated user holding the catalog.location.create permission register a URL whose raw string matches a trusted catalog.rules prefix (for example https://ghe.example.com/trusted/**) while the URL reader canonicalizes it to a location outside that prefix, so entity content from an untrusted source is ingested as if it came from a trusted one. Versions before 3.9.2 and 4.0.0 through 4.0.1 are affected, fixed in 3.9.2 (Backstage 1.54.10) and 4.0.2 (Backstage 1.56.1). Impact is scoped to the operator-configured ingestion policy boundary, downstream effects depend on deployment configuration, and no public exploit identified at time of analysis.
Improper access control in the @backstage/backend-defaults package of the Backstage developer portal framework (versions prior to 0.17.8, shipped in Backstage releases before v1.54.6) allows an authenticated user to invoke backend actions that an operator had explicitly excluded through backend.actions configuration. The excluded actions are filtered out when actions are listed, but the invocation path never re-applied those filters, so a caller who knows or guesses an action ID can still trigger it; per-action permissions and downstream authorization remain enforced, which caps the impact at a low-integrity exposure (CVSS 4.3, C:N/I:L/A:N). There is no public exploit identified at time of analysis and no confirmed active exploitation (not in CISA KEV), and the issue only matters in deployments that actually configured action exclusions. Fixed in @backstage/backend-defaults 0.17.8.
Improper entity validation in the deprecated Kubernetes services endpoint of @backstage/plugin-kubernetes-backend lets an authenticated Backstage user who already holds Kubernetes read permissions retrieve Kubernetes object metadata beyond their intended scope by submitting crafted entity data in the request body. The vulnerable handler trusted the caller-supplied entity reference instead of resolving it against the Backstage catalog, so the request was processed against an entity the user was not authorized for; the fix (0.21.8) parses the entity reference and performs a catalog lookup, returning 403 when no matching entity exists. Exposure is limited to read-only Kubernetes object metadata across configured clusters with no integrity or availability impact, and no public exploit code has been identified at time of analysis; exploitation is constrained to the legacy deprecated services endpoint and requires a crafted request that evades validation (AC:H).
Permission-filtered search in Backstage deployments that use an Elasticsearch or OpenSearch backend can return documents that a DENY policy should have withheld, because an empty list of permitted document types causes the engine to issue an unfiltered query across all indices instead of returning zero results. Only authenticated Backstage users (CVSS PR:L) are positioned to trigger this, and only when permission.enabled is set to true, the search backend is Elasticsearch/OpenSearch rather than the default in-memory engine, and the user is actually governed by a DENY policy for one or more search document types; the impact is limited to confidentiality (C:L) with no integrity or availability effect. The vendor has released fixes in @backstage/plugin-search-backend 2.1.6 and @backstage/plugin-search-backend-module-elasticsearch 1.8.7 (Backstage release v1.54.1), and there is no public exploit identified at time of analysis. Consistent with our independent assessment, this is a genuine but low-urgency information-disclosure issue rather than a high-priority emergency.
Sensitive information disclosure in the @backstage/plugin-kubernetes-backend package before version 0.21.9 allows an authenticated Backstage user who holds the standard Kubernetes resource read permission to retrieve Kubernetes Secret values that the plugin is designed to mask. The flaw is specifically reachable through the custom resources query path, where both the `data` and `stringData` fields of Secrets were returned unmasked, potentially exposing credentials and other confidential material held in connected clusters. Exposure is bounded by the Backstage service account's RBAC scope and by the targeted catalog entity's namespace and label selector, so deployments whose cluster credentials cannot read those resources are unaffected; there is no public exploit code identified at time of analysis and the issue carries a moderate CVSS of 5.0.
Path traversal in the Backstage Confluence-to-Markdown scaffolder module can let an authenticated Backstage user who runs a template with attacker-influenced Confluence content cause file writes outside the intended image directory, affecting integrity and potentially availability of the scaffolder workspace. The vulnerable package is @backstage/plugin-scaffolder-backend-module-confluence-to-markdown before 0.3.25; exploitation requires the optional module to be deployed and wired into a template, plus an attacker able to create or modify Confluence attachment metadata. There is no public exploit identified at time of analysis, and the issue is fixed in version 0.3.25 and Backstage release v1.54.6.
Filesystem path traversal in the Backstage TechDocs local publisher (@backstage/plugin-techdocs-node) can expose host files - such as /etc/passwd - to authenticated users of the documentation serving endpoint when the backend is configured with techdocs.publisher.type: 'local'. Exploitation requires a documentation source tree that already contains a symbolic link pointing outside the intended output directory, a precondition the vendor states does not arise through normal MkDocs operation, plus an authenticated user able to reach the endpoint (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.3, confidentiality-only impact). Cloud publishers (S3, GCS, Azure Blob Storage) are explicitly not affected, and no public exploit code has been identified at time of analysis; the issue is fixed in @backstage/plugin-techdocs-node 1.15.4.
Arbitrary file read in the Backstage TechDocs node plugin (@backstage/plugin-techdocs-node) prior to 1.15.4 allows an authenticated user who can register documentation sources to escape the intended documentation boundary. Because TechDocs only validated symlinks inside the docs_dir, an attacker-controlled source tree containing a symlink that resolves outside the tree (e.g. to /etc/passwd) plus an MkDocs snippets include directive ('--8<--') could pull that out-of-bounds file into the generated documentation, exposing anything readable by the build process. Exploitation requires authenticated access (PR:L), a crafted symlink/snippet chain (AC:H), and a deployment that builds docs from user-registerable sources; impact is confidentiality-only (C:H/I:N/A:N, CVSS 5.3), and no public exploit was identified at time of analysis.
Improper input validation in the Backstage Scaffolder backend (@backstage/plugin-scaffolder-backend) before version 4.1.0 allows an authenticated user with permission to create and read scaffolder tasks to influence how the task list endpoint orders results, enabling inference of confidential task data such as secrets. Exploitation is not straightforward: the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N (5.3 Medium), and the advisory requires four stacked preconditions - the target task's secrets must still be retained (not purged), the attacker must be able to see the target task, the attacker must already know the structure of the secret being inferred, and the attack depends on many repeated list requests - so the practical outcome is partial inference rather than guaranteed full secret disclosure. There is no public exploit identified at time of analysis, and no KEV listing; the issue is fixed in @backstage/plugin-scaffolder-backend 4.1.0 (Backstage release v1.54.6).
Sensitive-value disclosure in the @backstage/plugin-scaffolder-backend package prior to 4.1.0 lets an authenticated user who can create and read scaffolder tasks observe secret values in task logs and error messages. Exposure is conditional: it requires a deployment using the scaffolder permission framework with restrictive action permissions that actually deny an action, plus an affected template that passes a task secret, an environment secret, or a secret-derived 'each' key as input to that denied action. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV); risk is moderate and highly configuration-dependent because default deployments without action-level denials and templates that do not route secrets through denied actions are unaffected.
Information disclosure in the Backstage Scaffolder backend (@backstage/plugin-scaffolder-backend) prior to 4.1.0 allows an authenticated user who can run or view a Scaffolder task to recover backend-managed credentials from persisted task failure events. When a template injects secrets (for example via ${{ secrets.secret }}) into an action or checkpoint and that step fails, the raw secret values were written into the failure reason, error name, and error message without passing through the configured log redaction, and nested error objects were attached to the surfaced error. Exploitation requires a valid Backstage account (PR:L) and a narrow combination of template content and failure path (AC:H), so this is a genuine but moderate-priority CWE-532 leak rather than a broadly weaponizable flaw; no public exploit has been identified at time of analysis, and installations on @backstage/plugin-scaffolder-backend 4.1.0 or Backstage v1.54.6 and later are not affected.
Secret-derived values used during Scaffolder template iteration in Backstage can leak into task logs, exposing configured scaffolder.defaultEnvironment.secrets to anyone who can read those logs. Affected deployments run the @backstage/plugin-scaffolder-backend package prior to version 4.1.0, and exploitation requires a privileged, authenticated template author (PR:H in the CVSS vector) plus a deployment that has populated sensitive values in scaffolder.defaultEnvironment.secrets. The flaw only manifests when secret-derived values pass through a transforming Nunjucks filter inside an 'each' loop, since untransformed secrets were already redacted; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV). Realistic risk is moderate given the layered prerequisites, though the confidentiality impact for exposed credentials is high.
Inconsistent property-permission matching in the @backstage/plugin-catalog-backend package (Backstage releases prior to the fix) allows an authenticated user to receive catalog entity data that policy authors intended to restrict, because value-based catalog permission conditions evaluate keys and values inconsistently. Exposure is limited to deployments that use these value-based property conditions as a confidentiality boundary; installations without such value-based restrictions are not affected, and no public exploit has been identified at time of analysis. The issue is rated CVSS 4.3 (low severity, information disclosure only) and is fixed in @backstage/plugin-catalog-backend 3.9.1, shipped with Backstage release v1.54.6.
Backstage's catalog backend (the @backstage/plugin-catalog-backend package) prior to 3.9.1 enforces its allowedLocationTypes restriction inconsistently, letting a disallowed location type be processed when it is inherited from the parent/origin location rather than declared directly. An authenticated user who can register or influence a Location entity in a deployment that has configured an allowedLocationTypes list can therefore trigger the backend to resolve a location type it was supposed to reject, potentially reading files on the backend host. This is a low-severity issue: it requires non-default configuration plus authenticated access and a specific inheritance edge case, and no public exploit code has been identified at time of analysis; the fix is in @backstage/plugin-catalog-backend 3.9.1 (Backstage release v1.54.6).
Content injection in Backstage's cloud storage URL readers (the @backstage/backend-defaults package before 0.17.8) allows an attacker who holds write access to a configured AWS S3 bucket, AWS CodeCommit repository, or Azure Blob Storage container to craft object names containing path traversal segments so that an ingested object can collide with a protected file in the reader's output directory, overwriting or injecting content in certain deployment configurations. The issue is a CWE-22 improper-limitation-of-pathname flaw with an integrity-only impact, scored CVSS 4.4 (AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N), meaning exploitation demands high privileges (bucket write access) and a non-trivial collision condition, while confidentiality and availability are unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and a vendor patch is available in @backstage/backend-defaults 0.17.8 (Backstage v1.54.6).
Backstage deployments prior to 1.54.6 that use Azure Blob Storage or AWS S3 catalog sources can be induced to read catalog descriptors from outside the configured storage boundary - an object-storage path traversal in the cloud storage catalog providers and cloud URL readers. Exploitation requires an authenticated principal with high privileges (CVSS PR:H) who already has permission to create or rename objects in the trusted catalog bucket or container, and who then crafts object names containing dot-path segments (including encoded forms such as %2e%2e or backslash-delimited variants) to escape the intended prefix; the read is limited to locations reachable with the backend's own configured storage credentials, and impact is confidentiality-only (CVSS 3.0, AV:N/AC:H/PR:H/S:C/C:L/I:N/A:N). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; a vendor-released patch is available in 1.54.6.
Improper input validation in Backstage's @backstage/plugin-proxy-backend before 0.6.17 allows an authenticated user to craft a request URL containing path traversal sequences that the proxy forwards to a path outside the configured base path on an already-configured upstream target server. The flaw is bounded: the attacker must already hold an authenticated Backstage session (CVSS vector PR:L, unless an endpoint is deliberately configured with 'dangerously-allow-unauthenticated'), and only hosts that are already registered as proxy endpoints can be reached, so the escape is a redirect within an already-trusted target rather than a route to arbitrary internal systems. There is no indication of confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; the issue is addressed by vendor-released fixes in @backstage/plugin-proxy-backend 0.6.17 and Backstage release v1.54.6.
Improper input validation in the @backstage/plugin-techdocs-backend static content router (versions prior to 2.2.4) lets an authenticated Backstage user reach TechDocs static files outside the entity they are authorized to view when the Azure Blob Storage publisher provider is configured and entity-level permissions are enabled, resulting in high-confidentiality information disclosure. The flaw is a path traversal (CWE-22) reachable over the network by a low-privileged account, rated CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N); Azure-Blob-Storage-only scope and the required authenticated session keep realistic risk moderate. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor-released fix is @backstage/plugin-techdocs-backend 2.2.4, published in the Backstage monorepo release v1.54.6.
Authenticated users of Backstage TechDocs can bypass entity-scoped authorization and read documentation belonging to other entities by requesting a crafted /static/docs/... URL containing percent-encoded parent-directory (%2e%2e) segments. The issue is confined to deployments that combine the external TechDocs builder with an external storage provider (S3, GCS, etc.) and have the Backstage permission framework enabled; setups without the permission framework are unaffected because TechDocs content is intentionally readable by all authenticated users, and the default local builder/storage path is not exposed. Exploitation requires an authenticated account that already has access to at least one TechDocs site (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, 6.5), exposure is therefore limited to confidentiality of docs across entity boundaries, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Information disclosure in the Backstage Kubernetes backend plugin (@backstage/plugin-kubernetes-backend) before 0.21.10 allows an authenticated catalog contributor who can create or modify kubernetes-cluster Resource entities to steer cluster discovery into an unsupported authentication mode, causing the backend to answer Kubernetes API requests using its own local in-cluster service-account identity rather than a catalog-supplied credential. The disclosure is bounded strictly by what that pod service account is already permitted to read via RBAC, and the leaked credential is used only against the local in-cluster API endpoint and is never transmitted to the catalog-supplied endpoint; exploitation requires a non-default catalog cluster discovery deployment, the relevant endpoint permissions, and over-privileged pod RBAC, which is why the assessed severity is low. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in 0.21.10 (shipped in the Backstage release v1.54.6).
Improper authorization in Backstage's GitLab organization discovery plugin (@backstage/plugin-catalog-backend-module-gitlab) before 0.8.7 causes catalog user-creation events to be applied for GitLab accounts that are not members of the configured group, admitting an unintended catalog identity into the software catalog. Deployments that enable GitLab organization event ingestion and treat the scoped set of ingested catalog users as an access or sign-in boundary may consequently grant an attacker the permissions of a standard authenticated user, consistent with the assessed CVSS 3.1 vector 5.4 (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N), which confirms an authenticated precondition rather than unauthenticated exploitation. The vulnerable org-ingestion/events path is an optional, non-default configuration and no public exploit identified at time of analysis, so this is a moderate-severity authorization hygiene issue rather than an urgent, remotely exploitable bug.
An authenticated Backstage user who can run scaffolder templates can invoke built-in source-control actions (GitHub, GitLab, Azure DevOps, Bitbucket Cloud, Bitbucket Server) without supplying a personal SCM token, causing those actions to fall back to shared integration credentials and perform repository operations with broader privileges than the invoking user holds. The flaw affects deployments on Backstage versions prior to 1.54.6 that have SCM integration credentials configured; custom actions and SCM readers that do not accept a user-token input are unaffected. Exploitation requires the PR:L (authenticated) precondition and offers limited confidentiality and integrity impact with scope change, and no public exploit code has been identified at time of analysis.
Incorrect authorization in the Backstage scaffolder backend (@backstage/plugin-scaffolder-backend) prior to 4.1.0 lets an authenticated user with a valid portal account list scaffolder task metadata that the deployment's permission policy intended to restrict, yielding low-impact information disclosure (CVSS 3.1 base 4.3, PR:L - authentication requirements confirmed by the vector, which contains PR:L). Exposure is confined to task metadata because stored task secrets are not part of the affected response, and deployments that do not enforce a restrictive task visibility policy have essentially nothing to leak. No public exploit code was identified at time of analysis and the issue is not listed in CISA KEV; a vendor-released patch is available in version 4.1.0.
Improper authentication in the Backstage @backstage/plugin-auth-node package (versions 0.3.0 through 0.6.14 and 0.7.x before 0.7.5) lets an already-admitted identity-provider user assume another catalog user's identity and inherit its access and permissions. The flaw is conditional and rated CVSS 6.8 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N): it only triggers when a deployment uses an email-based sign-in resolver that derives catalog identity from the selected profile email AND that email carries an explicit negative verification flag (profile email verified:false, a matching raw provider email_verified:false, or an ID-token-only email with email_verified:false) - an absent email_verified claim alone is not affected. Vendor-released patches exist in 0.6.15 and 0.7.5 (Backstage releases v1.49.7 and v1.54.7), and no public exploit or confirmed active exploitation was identified at time of analysis.
Inconsistent repository filtering in Backstage's Bitbucket Server catalog backend module allows an authenticated Bitbucket Server user to inject catalog locations for repositories that the provider's configured filters are supposed to exclude. Only deployments of @backstage/plugin-catalog-backend-module-bitbucket-server (0.4.0 up to but not including 0.5.15) that use event-driven catalog updates AND configure projectKey, repoSlug, or skipArchivedRepos filters are affected; the attacker must have push access to a filtered-out repository that the Backstage integration credentials can still read. Impact is limited to unauthorized additions to the software catalog (integrity, not confidentiality or availability), no public exploit code has been identified at time of analysis, and exploitation requires valid Bitbucket Server authentication (PR:L) - so this is a genuine but moderate-priority authorization flaw rather than an emergency.
Inconsistent credential enforcement in the @backstage/plugin-proxy-backend package (versions 0.5.0 through 0.6.17) lets unauthenticated callers reach nested proxy upstreams that were explicitly configured to require credentials. When an operator defines an overlapping parent proxy path with credentials set to 'dangerously-allow-unauthenticated' and a nested child path under it with credentials set to 'require', the permissive parent exemption is applied to requests matched by the nested route, so the request is forwarded to the protected upstream and may be sent with static upstream credentials configured for that proxy. The CVSS vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) marks this as unauthenticated but high-complexity because exploitation depends on a specific overlapping proxy configuration rather than default settings; no public exploit code has been identified and the issue is not confirmed actively exploited (no CISA KEV listing).
OAuth authorization code theft in @backstage/plugin-auth-backend prior to 0.29.2 is possible when experimental dynamic client registration or CIMD features are enabled and configured with wildcard-hostname or protocol-less redirect URI allowlist patterns. Full-string glob matching allows a crafted attacker-controlled URI embedding a trusted hostname suffix in its path component to pass the allowlist, delivering authorization codes to the attacker after a victim completes an OAuth flow. No public exploit has been identified and this CVE does not appear in the CISA KEV catalog; real-world impact is sharply bounded by the experimental, disabled-by-default nature of the affected features.
### Impact A Server-Side Request Forgery (SSRF) vulnerability exists in `@backstage/plugin-auth-backend` when `auth.experimentalClientIdMetadataDocuments.enabled` is set to `true`. The CIMD metadata fetch validates the initial `client_id` hostname against private IP ranges but does not apply the same validation after HTTP redirects. The practical impact is limited. The attacker cannot read the response body from the internal request, cannot control request headers or method, and the feature must be explicitly enabled via an experimental flag that is off by default. Deployments that restrict `allowedClientIdPatterns` to specific trusted domains are not affected. ### Patches Patched in `@backstage/plugin-auth-backend` version `0.27.1`. The fix disables HTTP redirect following when fetching CIMD metadata documents. ### Workarounds Disable the experimental CIMD feature by removing or setting `auth.experimentalClientIdMetadataDocuments.enabled` to `false` in your app-config. This is the default configuration. Alternatively, restrict `allowedClientIdPatterns` to specific trusted domains rather than using the default wildcard pattern. ### References - [IETF Client ID Metadata Document draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) - [MCP Authorization Specification - Client ID Metadata Documents](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#client-id-metadata-documents)
Backstage TechDocs plugin versions prior to 1.13.11 and 1.14.1 contain a path traversal vulnerability that allows authenticated attackers to read arbitrary files from the host filesystem when the local generator is enabled. The vulnerability stems from insufficient symlink validation during the documentation build process, enabling attackers to embed sensitive file contents into generated HTML accessible to documentation viewers. Organizations using `techdocs.generator.runIn: local` with untrusted documentation sources are at risk until patching to the fixed versions.
Backstage is an open framework for building developer portals. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Backstage is an open framework for building developer portals. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Backstage is an open framework for building developer portals. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
A flaw was found in the Red Hat Developer Hub (RHDH). Rated medium severity (CVSS 5.7), this vulnerability is remotely exploitable, low attack complexity.
Backstage is an open platform for building developer portals. Rated critical severity (CVSS 9.9), this vulnerability is remotely exploitable, low attack complexity. This Code Injection vulnerability could allow attackers to inject and execute arbitrary code within the application.
@backstage/plugin-scaffolder-backend is the backend for the default Backstage software templates. Rated high severity (CVSS 8.5), this vulnerability is remotely exploitable, low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.
Backstage is an open platform for building developer portals. Rated medium severity (CVSS 4.9), this vulnerability is remotely exploitable, low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.
Backstage is an open platform for building developer portals, and techdocs-common contains common functionalities for Backstage's TechDocs. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. This Path Traversal vulnerability could allow attackers to access files and directories outside the intended path.