Devanshbatham

**Name of the Vulnerable Software and Affected Versions** Harden-Runner versions 2.15.1 and below **Description** Harden-Runner, a CI/CD security agent functioning as an EDR for GitHub Actions runners, contains a DNS over HTTPS (DoH) issue. This allows attackers to circumvent network restrictions imposed by the `egress-policy: block` setting by tunneling exfiltrated data through permitted HTTPS endpoints, such as `dns.google`. The attack involves encoding sensitive data, like the runner's hostname, as subdomains within DoH queries. These queries appear as legitimate HTTPS traffic to Harden-Runner’s domain-based filtering but are ultimately forwarded to a domain controlled by the attacker, enabling data exfiltration without directly connecting to blocked destinations. Exploitation requires pre-existing code execution within the GitHub Actions workflow. The Enterprise Tier of Harden-Runner is not affected. **Recommendations** Upgrade to Harden-Runner version 2.16.0 or later.

**Name of the Vulnerable Software and Affected Versions** Harden-Runner versions 2.15.1 and below **Description** Harden-Runner, a CI/CD security agent functioning as an EDR for GitHub Actions runners, has an issue where the `egress-policy: block` network restriction can be bypassed using DNS queries over TCP. When `egress-policy: block` is enabled with a restrictive `allowed-endpoints` list, non-compliant traffic should be denied. However, DNS queries over TCP are not adequately restricted, allowing tools like `dig` to initiate TCP-based DNS queries without being blocked. This requires an attacker to already have code execution capabilities within the GitHub Actions workflow. The Enterprise Tier of Harden-Runner is not affected. **Recommendations** Upgrade to Harden-Runner version 2.16.0 or later.

**Name of the Vulnerable Software and Affected Versions** Parse Server versions prior to 8.6.10 Parse Server versions prior to 9.5.0-alpha.11 **Description** Parse Server is an open source backend deployable on Node.js infrastructures. The Google, Apple, and Facebook authentication adapters utilize JWT verification to validate identity tokens. When the adapter’s audience configuration option is not set (clientId for Google/Apple, appIds for Facebook), JWT verification bypasses audience claim validation. This allows an attacker to use a validly signed JWT issued for a different application to authenticate as any user on the target Parse Server. The issue affects the authentication process when using Google, Apple, and Facebook authentication adapters. The vulnerable component relies on JWT (JSON Web Token) verification for identity validation. **Recommendations** Update Parse Server to version 8.6.10 or later. Update Parse Server to version 9.5.0-alpha.11 or later.

**Name of the Vulnerable Software and Affected Versions** Parse Server versions prior to 8.6.5 Parse Server versions prior to 9.5.0-alpha.3 **Description** The `readOnlyMasterKey` can be misused to create and delete files through the Files API. Specifically, the API endpoints `/files/:filename` (POST and DELETE methods) are affected. This bypasses the intended read-only restriction associated with the `readOnlyMasterKey`, allowing unauthorized file manipulation. An attacker possessing the `readOnlyMasterKey` can upload arbitrary files or delete existing ones. Any Parse Server deployment utilizing the `readOnlyMasterKey` and exposing the Files API is susceptible to this issue. **Recommendations** Versions prior to 8.6.5 should be updated to version 8.6.5 or later. Versions prior to 9.5.0-alpha.3 should be updated to version 9.5.0-alpha.3 or later. As a workaround, restrict network access to the `/files/:filename` API endpoints. Alternatively, avoid using the `readOnlyMasterKey`.

**Name of the Vulnerable Software and Affected Versions** Parse Server versions prior to 8.6.6 Parse Server versions prior to 9.5.0-alpha.4 **Description** Parse Server is an open-source backend deployable on Node.js infrastructures. A read-only master key can be used to call the `POST /loginAs` API endpoint, allowing the creation of a valid session token for any user. This enables a read-only credential to impersonate any user, gaining full read and write access to their data. Any Parse Server deployment utilizing the `readOnlyMasterKey` is potentially affected. The fix involves adding a check to the `/logInAs` handler. **Recommendations** Versions prior to 8.6.6 should be updated to version 8.6.6 or later. Versions prior to 9.5.0-alpha.4 should be updated to version 9.5.0-alpha.4 or later. As a workaround, avoid using the `readOnlyMasterKey`.

**Name of the Vulnerable Software and Affected Versions** Parse Server versions prior to 8.6.4 Parse Server versions prior to 9.4.1-alpha.3 **Description** Parse Server deployments utilizing the `readOnlyMasterKey` option are susceptible to unauthorized modifications. The `readOnlyMasterKey` is intended to grant read-only access, but certain endpoints incorrectly permit mutating operations when using this key. This allows an attacker possessing the `readOnlyMasterKey` to create, modify, and delete Cloud Hooks and initiate Cloud Jobs, potentially leading to data exfiltration. The vulnerable endpoints incorrectly process the `readOnlyMasterKey` for operations that should be restricted. The `readOnlyMasterKey` variable is misused in authorization checks. **Recommendations** Parse Server versions prior to 8.6.4 should be upgraded to version 8.6.4 or later. Parse Server versions prior to 9.4.1-alpha.3 should be upgraded to version 9.4.1-alpha.3 or later. If upgrading is not immediately possible, ensure the `readOnlyMasterKey` value is not shared with untrusted parties.

**Name of the Vulnerable Software and Affected Versions** Harden-Runner versions prior to 2.14.2 **Description** Harden-Runner is a CI/CD security agent designed to function like an EDR for GitHub Actions runners. A security issue has been identified in the Community Tier of Harden-Runner that allows outbound network connections to bypass audit logging. Specifically, outbound traffic utilizing the `sendto`, `sendmsg`, and `sendmmsg` socket system calls can evade detection and logging when the `egress-policy` is set to 'audit'. This bypass requires an attacker to already have code execution capabilities within the GitHub Actions workflow. The issue does not affect the Enterprise Tier. The vulnerability stems from incomplete monitoring coverage of certain socket-related system calls, allowing attackers to establish covert communication channels using UDP traffic without generating audit events. **Recommendations** Upgrade to Harden-Runner version 2.14.2 or later.

**Name of the Vulnerable Software and Affected Versions** Hono versions prior to 4.11.7 **Description** The IP Restriction Middleware in Hono does not properly validate IPv4 addresses, allowing attackers to bypass IP-based access controls. The `IPV4 REGEX` pattern and `convertIPv4ToBinary` function in `src/utils/ipaddr.ts` fail to ensure that IPv4 octet values are within the valid range of 0-255. This allows the creation of malformed IP addresses that circumvent intended restrictions. **Recommendations** Update to version 4.11.7 or later.

**Name of the Vulnerable Software and Affected Versions** Hono versions prior to 4.11.4 **Description** Hono is a Web application framework supporting various JavaScript runtimes. A flaw exists in the JWT verification middleware when using JWK/JWKS, where the `alg` value in the JWT header could influence signature verification even if the selected JWK did not explicitly define an algorithm. This could lead to JWT algorithm confusion, potentially allowing forged tokens to be accepted. The fix involves requiring the `alg` option to be explicitly specified in the JWT middleware, preventing the use of untrusted JWT header values to determine the verification algorithm. **Recommendations** Update to Hono version 4.11.4 or later.

**Name of the Vulnerable Software and Affected Versions** Hono versions prior to 4.11.4 **Description** Hono is a Web application framework supporting various JavaScript runtimes. A flaw exists in the JWK/JWKS JWT verification middleware where the algorithm specified in the JWT header could influence signature verification when the selected JWK did not explicitly define an algorithm. This could lead to JWT algorithm confusion, potentially allowing forged tokens to be accepted. The middleware has been updated to require an explicit allowlist of asymmetric algorithms for token verification, preventing the derivation of the verification algorithm from untrusted JWT header values. **Recommendations** Update to Hono version 4.11.4 or later.