ghsa

** UNSUPPORTED WHEN ASSIGNED ** Improper Output Neutralization for Logs vulnerability in Apache Struts. This issue affects Apache Struts Extras: before 2. When using LookupDispatchAction, in some cases, Struts may print untrusted input to the logs without any filtering. Specially-crafted input may lead to log output where part of the message masquerades as a separate log line, confusing consumers of the logs (either human or automated).  As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

### Summary An attacker can inject extra commits into the pack sent to GitHub, commits that aren’t pointed to by any branch. Although these “hidden” commits never show up in the repository’s visible history, GitHub still serves them at their direct commit URLs. This lets an attacker exfiltrate sensitive data without ever leaving a trace in the branch view. We rate this a High‑impact vulnerability because it completely compromises repository confidentiality. ### Details The proxy currently trusts only the ref‑update line (`oldOid → newOid`) and doesn't inspect the packfile’s contents Because the code only runs `git rev-list oldOid..newOid` to compute **introducedCommits** but **never** checks which commits actually arrived in the pack, a malicious client can append extra commits. Those “hidden” commits won’t be pointed to by any branch but GitHub still stores and serves them by SHA. <img width="2556" height="744" alt="Screenshot 2025-07-16 at 12 29 19" src="https://github.com/user-a...

### Summary An attacker can exploit the way GitProxy handles new branch creation to bypass the approval of prior commits on the parent branch. Because it can greatly affect system integrity, we classify this as a High impact vulnerability. ### Details GitProxy checks for the `0000000000000000000000000000000000000000` hash to detect new branches. This is used to process the commit accordingly in both `getDiff.ts` and `parsePush.ts`. However, the logic can be exploited as follows: 1. Make a commit in branch `a` (could be `main`) 2. Make a new branch `b` from that commit 3. Make a new commit in `b`, then approve it/get it approved 4. Go back to `a`, and attempt to push this commit to the proxy The unapproved commit from `a` will be pushed to the remote. ### PoC To reproduce this vulnerability: 1. Clone the target repository and make an unapproved commit on a mainline branch (e.g. main): ```bash git checkout -b a origin/main echo "DEBUG=true" > config.env git add config.env git comm...

### Summary An attacker can craft a malicious Git packfile to exploit the PACK signature detection in the `parsePush.ts`. By embedding a misleading PACK signature within commit content and carefully constructing the packet structure, the attacker can trick the parser into treating invalid or unintended data as the packfile. Potentially, this would allow bypassing approval or hiding commits. ### Details The affected version of `parsePush.ts` attempts to locate the Git PACK file by looking for the last occurrence of the string "PACK" in the incoming push payload: ```ts const packStart = buffer.lastIndexOf('PACK'); ``` This assumes that any "PACK" string near the end of the push is the beginning of the actual binary Git packfile. However, Git objects (commits, blobs, etc.) can contain arbitrary content (including the word PACK) in binary or non-compressed blobs. An attacker could abuse this by: 1. Crafting a custom packfile using low-level Git tools or by manually forging one 2. Placi...

### Summary This vulnerability allows a user to push to the remote repository while bypassing policies and explicit approval. Since checks and plugins are skipped, code containing secrets or unwanted changes could be pushed into a repository. Because it can allow policy violations to go undetected, we classify this as a High impact vulnerability. ### Details The source of the vulnerability is the push parser action `parsePush.ts`. It reads the first branch and parses it, while ignoring subsequent branches (silently letting them go through). Although the fix involves multiple improvements to the commit and push parsing logic, the core solution is to prevent multiple branch pushes from going through in the first place: ```ts if (refUpdates.length !== 1) { step.log('Invalid number of branch updates.'); step.log(`Expected 1, but got ${refUpdates.length}`); step.setError('Your push has been blocked. Please make sure you are pushing to a single branch.'); action.addStep(step); ...

### Summary Untrusted, user-controlled data from the HTTP Proxy-Authorization header can induce a denial of service state. ### Details Untrusted data is extracted from the user-controlled HTTP Proxy-Authorization header and passed to Extension::try_from and flows into parse_ttl_extension where it is parsed as a TTL value. If an attacker supplies a TTL of zero (e.g. by using a username such as 'configuredUser-ttl-0'), the modulo operation 'timestamp % ttl' will cause a division by zero panic, causing the server to crash causing a denial-of-service. The code assumed to be responsible for this can be found here: https://github.com/0x676e67/vproxy/blob/ab304c3854bf8480be577039ada0228907ba0923/src/extension.rs#L173-L183 ### PoC 1. Download and run the latest version of vproxy 2. Send a cUrl request like the following, adjusting address and port as necessary: ```curl -x "http://test-ttl-0:test@127.0.0.1:8101" https://google.com``` 3. Wait for a cUrl error indicating "Proxy CONNECT aborted...

The `--gitlab-group` flag for group-based authorization in the GitLab provider stopped working in the v7.0.0 release. Regardless of the flag settings, authorization wasn't restricted. Additionally, any authenticated users had whichever groups were set in `--gitlab-group` added to the new `X-Forwarded-Groups` header to the upstream application. While adding GitLab project based authorization support in #630, a bug was introduced where the user session's groups field was populated with the `--gitlab-group` config entries instead of pulling the individual user's group membership from the GitLab Userinfo endpoint. When the session groups where compared against the allowed groups for authorization, they matched improperly (since both lists were populated with the same data) so authorization was allowed. ### Impact This impacts GitLab Provider users who relies on group membership for authorization restrictions. Any authenticated users in your GitLab environment can access your application...

### Impact A specially crafted GIF file containing a malformed comment extension block (with a missing block terminator) can cause the ImageSharp GIF decoder to enter an infinite loop while attempting to skip the block. This leads to a denial of service. Applications processing untrusted GIF input should upgrade to a patched version. ### Patches The problem has been patched. All users are advised to upgrade to v3.1.11 or v2.1.11. ### Workarounds None.

### Summary A denial-of-service vulnerability exists in ruby-saml even with the message_max_bytesize setting configured. The vulnerability occurs because the SAML response is validated for Base64 format prior to checking the message size, leading to potential resource exhaustion. ### Details `ruby-saml` includes a `message_max_bytesize` setting intended to prevent DOS attacks and decompression bombs. However, this protection is ineffective in some cases due to the order of operations in the code: https://github.com/SAML-Toolkits/ruby-saml/blob/fbbedc978300deb9355a8e505849666974ef2e67/lib/onelogin/ruby-saml/saml_message.rb ```ruby def decode_raw_saml(saml, settings = nil) return saml unless base64_encoded?(saml) # <--- Issue here. Should be moved after next code block. settings = OneLogin::RubySaml::Settings.new if settings.nil? if saml.bytesize > settings.message_max_bytesize raise ValidationError.new("Encoded SAML Message exceeds " + setting...

### Summary A log injection vulnerability was identified in `pyload` in API `/json/add_package`. This vulnerability allows user with add packages permission to inject arbitrary messages into the logs gathered by `pyload`. ### Details `pyload` will generate a log entry when creating new package using API `/json/add_package`. This entry will be in the form of `Added package 'NAME_OF_PACKAGE' containing 'NUMBER_OF_LINKS' links`. However, when supplied with the name of new package containing a newline, this newline is not properly escaped. Newlines are also the delimiter between log entries. This allows the attacker to inject new log entries into the log file. ### PoC Run `pyload` in the default configuration by running the following command ``` pyload ``` We can now sign in as the pyload user who at least have add packages permissions. In my example, I will use the admin account to demonstrate this vulnerability. Now as an admin user, view the logs at `http://localhost:8000/logs` <img wi...