Use after free in Input in Google Chrome on Android prior to 148.0.7778.168 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)

Use after free in FileSystem in Google Chrome prior to 148.0.7778.168 allowed a remote attacker who convinced a user to engage in specific UI gestures to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)

Use after free in UI in Google Chrome prior to 148.0.7778.168 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical)

Integer overflow in Skia in Google Chrome on Windows prior to 148.0.7778.168 allowed a remote attacker who had compromised the renderer process to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: Critical)

Heap buffer overflow in WebML in Google Chrome prior to 148.0.7778.168 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: Critical)

Fleet is open source device management software. Prior to version 4.80.1, a vulnerability in Fleet's IP extraction logic allows unauthenticated attackers to bypass API rate limiting by spoofing client IP headers. This may allow brute-force login attempts or other abuse against Fleet instances exposed to the public internet. Fleet extracted client IP addresses from request headers (`True-Client-IP`, `X-Real-IP`, `X-Forwarded-For`) without validating that those headers originate from a trusted proxy. The extracted IP is used as the key for rate limiting and IP ban decisions. As a result, an attacker could rotate the value of these headers on each request, causing Fleet to treat each attempt as coming from a different client. This effectively bypasses per-IP rate limits on sensitive endpoints such as the login API, enabling unrestricted brute-force or credential stuffing attacks. This issue primarily affects Fleet instances that are directly exposed to the internet without a reverse proxy that overwrites forwarded-IP headers. Instances behind a properly configured proxy or WAF are less affected. Version 4.80.1 contains a patch. If an immediate upgrade is not possible, administrators should ensure Fleet is deployed behind a reverse proxy (e.g., nginx, Cloudflare, AWS ALB) that overwrites `X-Forwarded-For` with the true client IP, and apply rate limiting at the proxy or WAF layer.

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. From to 1.8.7-r1, a wrong NULL check after an allocation call in sixel_decode_raw and sixel_decode causes a NULL pointer dereference whenever the allocation fails. The check tests the address of the output parameter (always non-NULL) instead of the value the malloc returned. On allocation failure, the function continues and writes through a NULL pointer, crashing the process. This is a denial of service against any caller of these public APIs that hits a low-memory condition. This vulnerability is fixed in 1.8.7-r2.

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. From to 1.8.7-r1, a signed integer overflow in the SIXEL parser's image-buffer doubling loop can lead to an out-of-bounds heap write in sixel_decode_raw_impl. context->pos_x grows by repeat_count on every sixel character with no upper bound check. Once pos_x approaches INT_MAX, the expression "pos_x + repeat_count" used to size the image buffer overflows signed int. Depending on how the overflow wraps, the resize check that should reject oversized buffers can be bypassed, after which a subsequent write computes a large attacker-influenced offset into image->data and writes past the allocation. Reachable from any caller that decodes attacker-supplied SIXEL data, including img2sixel. This vulnerability is fixed in 1.8.7-r2.

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. From to 1.8.7-r1, signed integer overflow in sixel_encode_highcolor's allocation size calculation can lead to a heap buffer overflow. The public sixel_encode entry point validates only that width and height are greater than zero, with no upper bound. width and height are multiplied as plain int when computing the allocation size for paletted_pixels and normalized_pixels. Any caller that asks libsixel to encode a pixel buffer with width times height greater than INT_MAX (about 2.15 billion) will hit a wrapped allocation size; under the right wrap, the malloc succeeds with a buffer much smaller than the encoder expects, and the encoder writes past the end of the heap allocation. This vulnerability is fixed in 1.8.7-r2.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.18.0 and 3.1.13.0, the bounds check in TGAInput::decode_pixel computes k + palbytespp as unsigned 32-bit arithmetic. When k = 0xFFFFFFFC and palbytespp = 4, the addition wraps to 0, which compares less than palette_alloc_size and passes the check. The subsequent palette access uses the unwrapped k (0xFFFFFFFC) as the index, reading ~4 GB past the start of the palette buffer — SEGV. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.18.0 and 3.1.13.0, a signed 32-bit integer overflow in the loop index expression i * 4 inside SwapRGBABytes() causes the function to compute a large negative pointer offset when processing kABGR DPX images with large dimensions. The immediate crash is an out-of-bounds read (the memcpy at line 45 reads from &input[i * 4] first), but the subsequent write operations at lines 46–49 target the same wrapped offset — making this a combined OOB read+write primitive. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.18.0 and 3.1.13.0, a signed 32-bit integer overflow in the pixel-loop index expression i * 3 inside ConvertCbYCrYToRGB() causes the function to compute a large negative pointer offset into the output buffer, producing an out-of-bounds write that crashes the process. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.18.0 and 3.1.13.0, a signed integer overflow in QueryRGBBufferSizeInternal() in DPXColorConverter.cpp leads to a heap-based out-of-bounds write when processing crafted DPX image files. The function computes buffer sizes using 32-bit signed integer arithmetic with negative multipliers (e.g., pixels * -3 * bytes for kCbYCr descriptors and pixels * -4 * bytes for kABGR descriptors), where a negative result is used as an in-band signal that no separate buffer is needed. When the pixel count is sufficiently large, the multiplication overflows INT_MIN and wraps to a small positive value. The caller in dpxinput.cpp interprets this positive value as a required buffer size, allocates an undersized heap buffer via m_decodebuf.resize(), and then writes the full image data into it via fread, resulting in a heap buffer overflow. An attacker can exploit this by crafting a DPX file that triggers the overflow, causing a denial of service (crash) or potentially arbitrary code execution through heap corruption in any application that reads pixel data using OpenImageIO. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.18.0 and 3.1.13.0, a heap-based buffer overflow in the HEIF decoder of OpenImageIO allows out-of-bounds writes via crafted images due to a subimage metadata mismatch, leading to memory corruption and potential code execution. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.18.0 and 3.1.13.0, jpeg2000input.cpp:395 computes buffer size as const int bufsize = w * h * ch * buffer_bpp using signed 32-bit arithmetic. When the product exceeds INT_MAX, the result wraps to 0 or a small value. m_buf.resize() allocates an undersized buffer, and subsequent pixel write loops cause heap overflow. Conditional on USE_OPENJPH build flag. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.18.0 and 3.1.13.0, softimageinput.cpp:469 (mixed RLE) and :345 (pure RLE) do not clamp the run length to remaining scanline width before writing pixels. The raw packet path (line 403) correctly clamps with std::min, but RLE paths skip this check. A crafted .pic file causes heap overflow up to 65535 bytes. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0.

OpenImageIO is a toolset for reading, writing, and manipulating image files of any image file format relevant to VFX / animation. Prior to 3.0.18.0 and 3.1.13.0, sgiinput.cpp:265,274 use OIIO_DASSERT for bounds checking in the RLE decode loop. In release builds, OIIO_DASSERT compiles to ((void)sizeof(x)) (dassert.h:210), making all bounds checks no-ops. A crafted .sgi file with RLE count exceeding scanline width causes heap buffer overflow and crash. This vulnerability is fixed in 3.0.18.0 and 3.1.13.0.

Timing limitations of the HRNG in RS9116 when power save mode is enabled results in predictable values

Fleet is open source device management software. Prior to version 4.81.0, a vulnerability in Fleet's software installer pipeline could allow a crafted software package to execute arbitrary commands as root (macOS/Linux) or SYSTEM (Windows) on managed endpoints when an uninstall is triggered. When a software package (.pkg, .deb, .rpm, .exe, or .msi) is uploaded to Fleet, metadata is extracted from the package binary and used to generate uninstall scripts. In affected versions, this metadata is not properly sanitized before being included in the generated scripts. A specially crafted package containing malicious values in its metadata fields could result in unintended command execution when the uninstall script runs on managed endpoints. Version 4.81.0 contains a patch. If an immediate upgrade is not possible, administrators should avoid uploading software packages obtained from untrusted or unverified sources. Additionally, administrators can manually inspect and edit auto-generated uninstall scripts before deployment.

Fleet is open source device management software. Prior to version 4.81.0, Fleet contained a denial-of-service (DoS) issue in the gRPC Launcher `PublishLogs` endpoint. In affected versions, certain unexpected input values were not handled gracefully, which could cause the Fleet server process to terminate while processing an authenticated request from an enrolled Launcher host. An authenticated attacker with access to any enrolled Launcher node key could cause an immediate and complete denial of service by sending a single gRPC request to the `PublishLogs` endpoint. This vulnerability impacts availability only. There is no exposure of sensitive data, no authentication bypass, no privilege escalation, and no integrity impact. Version 4.81.0 contains a patch. If upgrading immediately is not possible, the following mitigations can reduce exposure. Restrict network access to the Fleet gRPC endpoint where feasible (for example, limiting inbound access to known host IP ranges); deploy Fleet behind infrastructure that terminates or filters gRPC traffic if Launcher log ingestion is not required; and/or monitor for repeated Fleet process crashes or unexpected restarts indicating potential exploitation.

Fleet is open source device management software. Prior to version 4.82.0, a vulnerability in Fleet's Windows MDM enrollment flow allows authentication tokens from any Azure AD tenant to be accepted. Because Fleet validates JWT signatures using Microsoft's multi-tenant JWKS endpoint but does not enforce the `aud` (audience) or `iss` (issuer) claims, any Microsoft-signed Azure AD access token containing the expected scopes can be used to authenticate to Fleet's MDM endpoints. If Windows MDM is enabled, an attacker with access to any Azure AD tenant can obtain a valid Microsoft-signed token and use it to enroll unauthorized devices and interact with Fleet's MDM management APIs. During device management, Fleet may expose sensitive enrollment secrets embedded in MDM command payloads, enabling further unauthorized access. Version 4.82.0 contains a patch. If an immediate upgrade is not possible, affected Fleet users should temporarily disable Windows MDM.

Fleet is open source device management software. Prior to version 4.80.1, Fleet trusted client-supplied IP address headers when determining the source IP for incoming requests. This allowed authenticated and unauthenticated clients to spoof their apparent IP address and bypass per-IP rate limiting controls. Fleet determines a client’s public IP address using HTTP headers such as X-Forwarded-For, X-Real-IP, and/or True-Client-IP. These headers were trusted without validation. An attacker could supply arbitrary values in these headers, causing Fleet to treat each request as originating from a different IP address. This could allow an attacker to bypass per-IP rate limits and increase the effectiveness of brute-force or password-spraying attempts against authentication endpoints. This issue does not allow authentication bypass, privilege escalation, data exposure, or remote code execution on its own. Version 4.80.1 contains a patch. As a workaround, run Fleet behind a trusted reverse proxy or load balancer that overwrites client IP headers.

Crabbox prior to v0.12.0 contains an authentication bypass vulnerability that allows non-admin shared-token callers to impersonate other owners or organizations by spoofing identity headers. Attackers can inject malicious X-Crabbox-Owner and X-Crabbox-Org headers in requests authenticated with a shared token to bypass authorization checks and access owner/org-scoped lease operations belonging to victim accounts.

SiYuan is an open-source personal knowledge management system. Prior to 3.7.0, SiYuan's Bazaar (community marketplace) renders the name and version fields of a package's plugin.json (and the equivalent theme.json / template.json / widget.json / icon.json) into the Settings → Marketplace UI without HTML escaping. The kernel-side helper sanitizePackageDisplayStrings in kernel/bazaar/package.go HTML-escapes only Author, DisplayName, and Description — Name and Version flow through to the renderer raw. The frontend at app/src/config/bazaar.ts substitutes them into HTML template strings via ${item.preferredName} / ${data.name} / v${data.version} and assigns the result to innerHTML. As a consequence, malicious HTML in either field is parsed and executed when a user opens the marketplace tab. This vulnerability is fixed in 3.7.0.

SiYuan is an open-source personal knowledge management system. Prior to 3.7.0, SiYuan publish-mode Reader can mutate Conf and SQL index via 8 ungated APIs. POST /api/graph/getGraph, POST /api/graph/getLocalGraph, POST /api/sync/setSyncInterval, POST /api/storage/updateRecentDocViewTime, POST /api/storage/updateRecentDocCloseTime, POST /api/storage/updateRecentDocOpenTime, POST /api/storage/batchUpdateRecentDocCloseTime, and POST /api/search/updateEmbedBlock are registered with model.CheckAuth only, omitting both model.CheckAdminRole and model.CheckReadonly. Each of them writes server-side state, including atomic rewrites of <workspace>/conf/conf.json via model.Conf.Save(). Any caller whose JWT passes CheckAuth, including a publish-service RoleReader (the role assigned to anonymous publish visitors) and a RoleEditor against a workspace where Editor.ReadOnly = true, can hit them This vulnerability is fixed in 3.7.0.