#git

### Summary A memory leak vulnerability exists in the `LoadOpenCLDeviceBenchmark()` function in `MagickCore/opencl.c`. When parsing a malformed OpenCL device profile XML file that contains `<device` elements without proper `/>` closing tags, the function fails to release allocated memory for string members (`platform_name`, `vendor_name`, `name`, `version`), leading to memory leaks that could result in resource exhaustion. **Affected Version**: ImageMagick 7.1.2-12 and possibly earlier versions --- ### Details The vulnerability is located in `MagickCore/opencl.c`, function `LoadOpenCLDeviceBenchmark()` (lines 754-911). **Root Cause Analysis:** 1. When a `<device` tag is encountered, a `MagickCLDeviceBenchmark` structure is allocated (line 807-812) 2. String attributes (`platform`, `vendor`, `name`, `version`) are allocated via `ConstantString()` (lines 878, 885, 898, 900) 3. These strings are **only freed** when a `/>` closing tag is encountered (lines 840-849) 4. At function ex...

## Summary Stack overflow via infinite recursion in MSL (Magick Scripting Language) `<write>` command when writing to MSL format. ## Version - ImageMagick 7.x (tested on current main branch) - Commit: HEAD - Requires: libxml2 support (for MSL parsing) ## Steps to Reproduce ### Method 1: Using ImageMagick directly ```bash magick MSL:recursive.msl out.png ``` ### Method 2: Using OSS-Fuzz reproduce ```bash python3 infra/helper.py build_fuzzers imagemagick python3 infra/helper.py reproduce imagemagick msl_fuzzer recursive.msl ``` Or run the fuzzer directly: ```bash ./msl_fuzzer recursive.msl ``` ## Expected Behavior ImageMagick should handle recursive MSL references gracefully by detecting the loop and returning an error. ## Actual Behavior Stack overflow causes process crash: ``` AddressSanitizer:DEADLYSIGNAL ==PID==ERROR: AddressSanitizer: stack-overflow #0 MSLStartElement /src/imagemagick/coders/msl.c:7045 #1 xmlParseStartTag /src/libxml2/parser.c #2 xmlParseCh...

### Impact A denial-of-service vulnerability due to improper input validation allows a remote attacker to crash the service via a malformed HTTP header. Allows crashing the process with data coming from the network when used with, for example, an HTTP server. Most common way of using Swift W3C Trace Context is through Swift OTel. ### Patches https://github.com/swift-otel/swift-w3c-trace-context/commit/5da9b143ba6046734de3fa51dafea28290174e4e ### Workarounds Disable either Swift OTel or the code that extracts the trace information from an incoming header (such as a `TracingMiddleware`). ### References [Swift W3C TraceContext 1.0.0-beta.5](https://github.com/swift-otel/swift-w3c-trace-context/releases/tag/1.0.0-beta.5) [Swift OTel 1.0.4](https://github.com/swift-otel/swift-otel/releases/tag/1.0.4)

### Summary A vulnerability was discovered during a manual security audit of the AlchemyCMS source code. The application uses the Ruby `eval()` function to dynamically execute a string provided by the `resource_handler.engine_name` attribute in `Alchemy::ResourcesHelper#resource_url_proxy`. ### Details The vulnerability exists in `app/helpers/alchemy/resources_helper.rb` at line 28. The code explicitly bypasses security linting with `# rubocop:disable Security/Eval`, indicating that the use of a dangerous function was known but not properly mitigated. Since `engine_name` is sourced from module definitions that can be influenced by administrative configurations, it allows an authenticated attacker to escape the Ruby sandbox and execute arbitrary system commands on the host OS. But, for this attack to be possible local file access to the alchemy project or the source on a remote server is necessary in order to manipulate the module config file, though. ### PoC (Proof of Concept) The...

### Summary An integer overflow in the API component's protobuf decoder allows denial-of-service attacks when API encryption is not used. ### Details The bounds check `ptr + field_length > end` in `components/api/proto.cpp` can overflow when a malicious client sends a large `field_length` value. This affects all ESPHome device platforms (ESP32, ESP8266, RP2040, LibreTiny). The overflow bypasses the out-of-bounds check, causing the device to read invalid memory and crash. When using the plaintext API protocol, this attack can be performed without authentication. When noise encryption is enabled, knowledge of the encryption key is required. ### Affected Versions ESPHome 2025.9.0 through 2025.12.6 ### Mitigation - Upgrade to ESPHome 2025.12.7 or later (or 2026.1.0b3 or later) - [Enable API encryption](https://esphome.io/components/api.html#configuration-variables) with a unique key per device - Follow the [Security Best Practices](https://esphome.io/guides/security_best_practices/) #...

### Summary The JSONAuth.Auth function contains a logic flaw that allows unauthenticated attackers to enumerate valid usernames by measuring the response time of the /api/login endpoint. ### Details The vulnerability exists due to a "short-circuit" evaluation in the authentication logic. When a username is not found in the database, the function returns immediately. However, if the username does exist, the code proceeds to verify the password using bcrypt (users.CheckPwd), which is a computationally expensive operation designed to be slow. This difference in execution path creates a measurable timing discrepancy: Invalid User: ~1ms execution (Database lookup only). Valid User: ~50ms+ execution (Database lookup + Bcrypt hashing). In auth/json.go: ```go // auth/json.go line 54 u, err := usr.Get(srv.Root, cred.Username) // VULNERABILITY: // If 'err != nil' (User not found), the OR condition short-circuits. // The second part (!users.CheckPwd) is NEVER executed. // // If 'err == nil' (...

### Summary Markdown feature allows unrestricted server side html-rendering which allows arbitary file read (LFD) and fully SSRF access We in @0xL4ugh ( @abdoghazy2015, @xtromera, @A-z4ki, @ZeyadZonkorany and @KarimTantawey) During playing Null CTF 2025 that helps us solved a challenge with unintended way : ) Please note that we used the latest Version and deployed it via this dockerfile : Dockerfile: ``` FROM b3log/siyuan ENV TZ=America/New_York \ PUID=1000 \ PGID=1000 \ SIYUAN_ACCESS_AUTH_CODE=SuperSecretPassword RUN mkdir -p /siyuan/workspace COPY ./startup.sh /opt/siyuan/startup.sh RUN chmod +x /opt/siyuan/startup.sh EXPOSE 6806 ENTRYPOINT ["sh", "-c", "/opt/siyuan/startup.sh"] ``` startup.sh ```sh #!/bin/sh set -e echo "nullctf{secret}" > "/flag_random.txt" exec ./entrypoint.sh ``` docker-compose.yaml: ```yaml services: main: build: . ports: - 6806:6806 restart: unless-stopped environment: - TZ=America/New_York - PUID...

### Summary The SiYuan Note application (v3.5.3) contains a logic vulnerability in the /api/file/globalCopyFiles endpoint. The function allows authenticated users to copy files from any location on the server's filesystem into the application's workspace without proper path validation ### Details The vulnerability exists in the api/file.go source code. The function globalCopyFiles accepts a list of source paths (srcs) from the JSON request body. While the code checks if the source file exists using filelock.IsExist(src), it fails to validate whether the source path resides within the authorized workspace directory. ``` func globalCopyFiles(c *gin.Context) { // ... srcsArg := arg["srcs"].([]interface{}) for _, src := range srcs { if !filelock.IsExist(src) { ... } if err := filelock.Copy(src, dest); err != nil { ... } } } ``` ### PoC The following steps demonstrate how to exfiltrate the /etc/passwd file. 1. The attacker sends a request...

### Server-Side Request Forgery (SSRF) via HTML Check CSS Download The HTML Check feature (`/api/v1/message/{ID}/html-check`) is designed to analyze HTML emails for compatibility. During this process, the `inlineRemoteCSS()` function automatically downloads CSS files from external `<link rel="stylesheet" href="...">` tags to inline them for testing. #### Affected Components - **Primary File:** `internal/htmlcheck/css.go` (lines 132-207) - **API Endpoint:** `/api/v1/message/{ID}/html-check` - **Handler:** `server/apiv1/other.go` (lines 38-75) - **Vulnerable Functions:** - `inlineRemoteCSS()` - line 132 - `downloadToBytes()` - line 193 - `isURL()` - line 221 #### Technical Details **1. Insufficient URL Validation (`isURL()` function):** ```go // internal/htmlcheck/css.go:221-224 func isURL(str string) bool { u, err := url.Parse(str) return err == nil && (u.Scheme == "http" || u.Scheme == "https") && u.Host != "" } ``` **2. Unrestricted Download (`downloadToBytes()...

### Impact Arbitrary code execution in environments consuming generated clients This issue is similar in nature to the recently-patched MCP vulnerability (CVE-2026-22785), but affects a different code path in @orval/core that was not addressed by that fix. The vulnerability allows untrusted OpenAPI specifications to inject arbitrary TypeScript/JavaScript code into generated clients via the x-enumDescriptions field, which is embedded without proper escaping in getEnumImplementation(). I have confirmed that the injection occurs during const enum generation and results in executable code within the generated schema files. ### Patches Upgrade to Orval 8.0.2 ### References An example OpenAPI showing the issue: ```yaml openapi: 3.0.4 info: title: Enum PoC version: "1.0.0" paths: /ping: get: operationId: ping responses: "200": description: ok content: application/json: schema: $ref: "#/components...