#vulnerability

### 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...

### 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...

A Privilege Escalation vulnerability was identified in the Keycloak identity and access management solution, specifically when FGAPv2 is enabled in version 26.2.x. The flaw lies in the admin permission enforcement logic, where a user with manage-users privileges can self-assign realm-admin rights. The escalation occurs due to missing privilege boundary checks in role mapping operations via the admin REST interface. A malicious administrator with limited permissions can exploit this by editing their own user roles, gaining unauthorized full access to realm configuration and user data. This issue has been fixed in versions 26.2.6, and 26.3.0.

There is a flaw with the first login flow where, during a IdP login, an attacker with a registered account can initiate the process to merge accounts with an existing victim's account. The attacker will subsequently be prompted to "review profile" information, which allows the the attacker to modify their email address to that of a victim's account. This triggers a verification email sent to the victim's email address. If the victim clicks the verification link, the attacker can gain access to the victim's account. While not a zero-interaction attack, the attacker's email address is not directly present in the verification email content, making it a potential phishing opportunity. This issue has been fixed in versions 26.0.13, 26.2.6, and 26.3.0.

Akamai's latest Ransomware Report 2025 reveals "quadruple extortion," new AI-driven tactics by groups like Black Basta, FunkSec, and TrickBot, and growing threats to non-profits. Learn about evolving cyber threats.

Apple on Tuesday released security updates for its entire software portfolio, including a fix for a vulnerability that Google said was exploited as a zero-day in the Chrome web browser earlier this month. The vulnerability, tracked as CVE-2025-6558 (CVSS score: 8.8), is an incorrect validation of untrusted input in the browser's ANGLE and GPU components that could result in a sandbox escape via