ghsa

**Impact** An attacker can cause high CPU usage by sending a specially crafted p2p message. More details to be released later. **Credit** This issue was reported to the Ethereum Foundation Bug Bounty Program by @Yenya030

**Impact** A vulnerable node can be forced to shutdown/crash using a specially crafted message. More details to be released later. **Credit** This issue was reported to the Ethereum Foundation Bug Bounty Program by DELENE TCHIO ROMUALD.

## Summary A **path traversal vulnerability** exists in GuardDog's `safe_extract()` function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to **Arbitrary File Overwrite** and **Remote Code Execution** on systems running GuardDog. **CWE:** CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) ## Details ### Vulnerable Code **File:** `guarddog/utils/archives.py` ```python elif zipfile.is_zipfile(source_archive): with zipfile.ZipFile(source_archive, "r") as zip: for file in zip.namelist(): # Note: zip.extract cleans up any malicious file name # such as directory traversal attempts This is not the # case of zipfile.extractall zip.extract(file, path=os.path.join(target_directory, file)) # ❌ VULNERABLE ``` ### Root Cause The comment about `zip.extract()` fooled me at first :) then I noticed the `os.path.join()` call. The vulnerability stems fr...

## Summary GuardDog's `safe_extract()` function does not validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing attackers to cause denial of service through zip bombs. A malicious package can consume gigabytes of disk space from a few megabytes of compressed data. ## Vulnerability Details **Affected Component:** `guarddog/utils/archives.py` - `safe_extract()` function **Vulnerability Type:** CWE-409 - Improper Handling of Highly Compressed Data (Zip Bomb) **Severity:** HIGH (CVSS ~8) **Attack Vector:** Network (malicious package uploaded to PyPI/npm) or local ### Root Cause The `safe_extract()` function handles TAR files securely using the `tarsafe` library, but ZIP file extraction has no size validation: ```python elif zipfile.is_zipfile(source_archive): with zipfile.ZipFile(source_archive, "r") as zip: for file in zip.namelist(): zip.extract(file, path=os.path.join(target_directory, file)) ``` **Missing protections:*...

### Problem Local platform users who can write to TYPO3’s mail‑file spool directory can craft a file that the system will automatically deserialize without any class restrictions. This flaw allows an attacker to inject and execute arbitrary PHP code in the public scope of the web server. The vulnerability is triggered when TYPO3 is configured with `$GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport_spool_type'] = 'file';` and a scheduler task or cron job runs the command `mailer:spool:send`. The spool‑send operation performs the insecure deserialization that is at the core of this issue. ### Solution Update to TYPO3 versions 10.4.55 ELTS, 11.5.49 ELTS, 12.4.41 LTS, 13.4.23 LTS, 14.0.2 that fix the problem described. ### Credits Thanks to Vitaly Simonovich for reporting this issue, and to TYPO3 security team members Elias Häußler and Oliver Hader for fixing it. ### References * [TYPO3-CORE-SA-2026-004](https://typo3.org/security/advisory/typo3-core-sa-2026-004)

### Summary A TOCTOU race condition vulnerability allows a user to exceed the set number of active tunnels in their subscription plan. ### Details Affected conponent: `apps/web/src/routes/api/tunnel/register.ts` - `/tunnel/register` endpoint code-: ```ts // Check if tunnel already exists in database const [existingTunnel] = await db .select() .from(tunnels) .where(eq(tunnels.url, tunnelUrl)); const isReconnection = !!existingTunnel; console.log( `[TUNNEL LIMIT CHECK] Org: ${organizationId}, Tunnel: ${tunnelId}`, ); console.log( `[TUNNEL LIMIT CHECK] Is Reconnection: ${isReconnection}`, ); console.log( `[TUNNEL LIMIT CHECK] Plan: ${currentPlan}, Limit: ${tunnelLimit}`, ); // Check limits only for NEW tunnels (not reconnections) if (!isReconnection) { // Count active tunnels from Redis SET ...

### Summary This vulnerability allows a user i.e a free plan user to get more than the desired subdomains due to lack of db transaction lock mechanisms in `https://github.com/akinloluwami/outray/blob/main/apps/web/src/routes/api/%24orgSlug/subdomains/index.ts` ### Details - The affected code-: ```ts //Race condition const [subscription] = await db .select() .from(subscriptions) .where(eq(subscriptions.organizationId, organization.id)); const currentPlan = subscription?.plan || "free"; const planLimits = getPlanLimits(currentPlan as any); const subdomainLimit = planLimits.maxSubdomains; const existingSubdomains = await db .select() .from(subdomains) .where(eq(subdomains.organizationId, organization.id)); if (existingSubdomains.length >= subdomainLimit) { return json( { error: `Subdomain limit reached. The ${currentPlan} plan allows ${subdom...

## Summary A flaw in Hono’s JWK/JWKS JWT verification middleware allowed the algorithm specified in the JWT header to influence signature verification when the selected JWK did not explicitly define an algorithm. This could enable JWT algorithm confusion and, in certain configurations, allow forged tokens to be accepted. ## Details When verifying JWTs using JWKs or a JWKS endpoint, the middleware selected the verification algorithm based on the JWK’s `alg` field if present. If the JWK did not specify an algorithm, the middleware fell back to using the `alg` value provided in the unverified JWT header. Because the `alg` field in a JWK is optional and commonly omitted in real-world JWKS configurations, this behavior could allow an attacker to influence which algorithm is used for verification. In some environments, this may result in authentication or authorization bypass through crafted JWTs. The practical impact depends on application configuration, including which algorithms are ...

## Summary A flaw in Hono’s JWK/JWKS JWT verification middleware allowed the JWT header’s `alg` value to influence signature verification when the selected JWK did not explicitly specify an algorithm. This could enable **JWT algorithm confusion** and, in certain configurations, allow forged tokens to be accepted. ## Details When verifying JWTs using JWKs or a JWKS endpoint, the middleware selected the verification algorithm based on the JWK’s `alg` field if present, but otherwise fell back to the `alg` value provided in the unverified JWT header. Because the `alg` field in a JWK is optional and often omitted in real-world JWKS configurations, this behavior could allow an attacker to control the algorithm used for verification. In some environments, this may lead to authentication or authorization bypass through crafted tokens. The practical impact depends on application configuration, including which algorithms are accepted and how JWTs are used for authorization decisions. ## Im...

### Summary There is a Zip Slip path traversal vulnerability in the jaraco.context package affecting setuptools as well, in `jaraco.context.tarball()` function. The vulnerability may allow attackers to extract files outside the intended extraction directory when malicious tar archives are processed. The strip_first_component filter splits the path on the first `/` and extracts the second component, while allowing `../` sequences. Paths like `dummy_dir/../../etc/passwd` become `../../etc/passwd`. Note that this suffers from a nested tarball attack as well with multi-level tar files such as `dummy_dir/inner.tar.gz`, where the inner.tar.gz includes a traversal `dummy_dir/../../config/.env` that also gets translated to `../../config/.env`. The code can be found: - https://github.com/jaraco/jaraco.context/blob/main/jaraco/context/__init__.py#L74-L91 - https://github.com/pypa/setuptools/blob/main/setuptools/_vendor/jaraco/context.py#L55-L76 (inherited) This report was also sent to setuptoo...