#git

Cybersecurity researchers from Huntress detail a major VM Escape attack where hackers took over host servers. Using a secret toolkit called MAESTRO, the attackers stayed hidden for over a year. Read the exclusive details on how this breach was stopped and how to protect your network.

### Impact An attacker who exploits this vulnerability can craft a PDF which leads to possibly long runtimes for actually invalid files. This can be achieved by omitting the `/Root` entry in the trailer, while using a rather large `/Size` value. Only the non-strict reading mode is affected. ### Patches This has been fixed in [pypdf==6.6.0](https://github.com/py-pdf/pypdf/releases/tag/6.6.0). ### Workarounds ```python from pypdf import PdfReader, PdfWriter # Instead of reader = PdfReader("file.pdf") # use the strict mode: reader = PdfReader("file.pdf", strict=True) # Instead of writer = PdfWriter(clone_from="file.pdf") # use an explicit strict reader: writer = PdfWriter(clone_from=PdfReader("file.pdf", strict=True)) ``` ### Resources This issue has been fixed in #3594.

### Summary An authentication bypass vulnerability allows any unauthenticated attacker to forge arbitrary JWT tokens by setting "alg": "none" in the token header. The library's verification functions immediately return `true` for such tokens without performing any cryptographic verification, enabling complete impersonation of any user and privilege escalation. ### Details The vulnerability exists in Sources/JSONWebSignature/JWS+Verify.swift at lines 34-37: ``` public func verify<Key>(key: Key?) throws -> Bool { guard SigningAlgorithm.none != protectedHeader.algorithm else { return true // <-- Vulnerability: returns true without verification } ``` When the JWT header contains "alg": "none", the verify() method returns true immediately without: 1. Checking if the signature is empty or present 2. Validating the token against any key 3. Requiring explicit opt-in from the caller The SigningAlgorithm enum in Sources/JSONWebAlgorithms/Signatures/Signi...

### Vulnerability **Description** --- **Vulnerability Overview** This issue is a command injection vulnerability (CWE-78) that allows authenticated users to inject stdio_config.command/args into MCP stdio settings, causing the server to execute subprocesses using these injected values. The root causes are as follows: - **Missing Security Filtering**: When transport_type=stdio, there is no validation on stdio_config.command/args, such as allowlisting, enforcing fixed paths/binaries, or blocking dangerous options. - **Functional Flaw (Trust Boundary Violation)**: The command/args stored as "service configuration data" are directly used in the /test execution flow and connected to execution sinks without validation. - **Lack of Authorization Control**: This functionality effectively allows "process execution on the server" (an administrative operation), yet no administrator-only permission checks are implemented in the code (accessible with Bearer authentication only). **Vulnerable...

### Summary After WeKnora enables the Agent service, it allows users to call the database query tool. Due to insufficient backend validation, an attacker can use prompt‑based bypass techniques to evade query restrictions and obtain sensitive information from the target server and database. ### Details ### Source - **File**: `/internal/agent/tools/database_query.go` - **Function**: `validateAndSecureSQL()` (lines 249–373) - **API Endpoint**: `POST /api/v1/agent-chat/{session_id}` ### Sink - **File**: `/internal/agent/tools/database_query.go` - **Function**: `Execute()` (line 158: `t.db.WithContext(ctx).Raw(securedSQL).Rows()`) - **Description**: Raw SQL execution without parameterized queries Backend validation code: `/internal/agent/tools/database_query.go`, lines 273–281: ``` // 3. Check for allowed tables allowedTables := []string{ "tenants", "knowledge_bases", "knowledges", "sessions", "messages", "chunks", "embeddings", "models", } // Extract table names from FROM and ...

### Summary This notification is related to the use of specific values for the region input field when calling AWS services. An actor with access to the environment in which the SDK is used could set the region input field to an invalid value. A defense-in-depth enhancement has been implemented in the AWS SDK for .NET v4. This enhancement validates that a region used to construct an endpoint URL is a valid host label. The change was released on Nov 21, 2025. This advisory is informational to help customers understand their responsibilities regarding configuration security. ### Impact Customer applications could be configured to improperly route AWS API calls to non-existent or non-AWS hosts. While the SDK was functioning safely within the requirements of the shared responsibility model, additional safeguards have been added to support secure customer implementations. Impacted versions: All versions of the AWS SDK for .NET V4 prior to the 4.0.139.0 release (the AWS SDK for .NET V3 wa...

A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular Template Compiler. The vulnerability exists because Angular’s internal sanitization schema fails to recognize the `href` and `xlink:href` attributes of SVG `<script>` elements as a **Resource URL** context. In a standard security model, attributes that can load and execute code (like a script's source) should be strictly validated. However, because the compiler does not classify these specific SVG attributes correctly, it allows attackers to bypass Angular's built-in security protections. When template binding is used to assign user-controlled data to these attributes for example, `<script [attr.href]="userInput">` the compiler treats the value as a standard string or a non-sensitive URL rather than a resource link. This enables an attacker to provide a malicious payload, such as a `data:text/javascript` URI or a link to an external malicious script. ### Impact When successfully exploited, this vulnerabili...

### Impact Anyone who has view rights on the `Calendar.JSONService` page, including guest users can exploit this vulnerability by accessing database info or starting a DoS attack. ### Workarounds Remove the `Calendar.JSONService` page. This will however break some functionalities. ### References Jira issue: * [FULLCAL-80: SQL injection through Calendar.JSONService](https://jira.xwiki.org/browse/FULLCAL-80) * [FULLCAL-81: SQL injection through Calendar.JSONService still exists](https://jira.xwiki.org/browse/FULLCAL-81) ### For more information If there are any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email [Security Mailing List](mailto:security@xwiki.org)

### Impact Anyone who has view rights on the `Calendar.JSONService` page, including guest users can exploit this vulnerability by accessing database info, with the exception of passwords. ### Workarounds Remove the `Calendar.JSONService` page. This will however break some functionalities. ### References Jira issue: * [FULLCAL-82: Calendar.JSONService exposes emails of all users](https://jira.xwiki.org/browse/FULLCAL-82) ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@xwiki.org)

A cross-site scripting (XSS) vulnerabilities was identified in October CMS backend configuration forms: - **Editor Settings Markup Styles** A user with the `Global Editor Settings` permission could inject malicious HTML/JS into the stylesheet input at *Settings → Editor Settings → Markup Styles*. A specially crafted input could break out of the intended `<style>` context, allowing arbitrary script execution across backend pages for all users. --- ### Impact - Persistent XSS across the backend interface. - Exploitable by lower-privileged accounts with the above permissions. - Potential consequences include privilege escalation, session hijacking, and execution of unauthorized actions in victim sessions. --- ### Patches The vulnerability has been patched in **v4.0.12** and **v3.7.13**. Stylesheet inputs are now sanitized to prevent injection of arbitrary HTML/JS. All users are strongly encouraged to upgrade to the latest patched version. --- ### Workarounds I...