A type allow-list bypass in the BSON serialization library of the MongoDB C# Driver allows a type-restriction check to be circumvented when polymorphic data is deserialized into loosely typed members. An unauthorized party who can supply or plant BSON/JSON data that the application later deserializes can cause the application process to instantiate .NET types outside the intended allow-list and populate them with unauthorized party-controlled values. In applications that contain a suitable gadget type, this can lead to arbitrary code execution in the context of the application, with corresponding loss of confidentiality, integrity, and availability. No special privileges beyond the ability to introduce data the application reads are required.
A deserialization type-restriction control in the BSON serialization component can be bypassed because the check used to recognize a class of compiler-generated types relies on an overly permissive heuristic rather than a precise identification. An unauthorized party able to supply BSON content that an application later deserializes into a loosely typed member can cause types outside the intended allow-list to be constructed and populated with unauthorized party-supplied values inside the consuming application. This can lead to unexpected object state and errors in downstream application logic. No elevated privileges beyond the ability to place unauthorized party-influenced content in the deserialization path are required.
A memory-safety flaw in the key-management request-building component of the library can lead to an out-of-bounds write on the heap. A fixed-size output buffer is used under an assumption about cryptographic key size that is never validated, so when the library is embedded by a caller that supplies its own cryptographic callback implementation, data larger than the buffer can be written past its end. Exploitation requires the ability to control the embedding application's in-process key-management provider configuration, a high-privilege position. The demonstrated impact is memory corruption resulting in abnormal termination of the client process.
A critical vulnerability in Active Storage's image analysis using ImageMagick allows unauthenticated attackers to write arbitrary files on the server and read sensitive files when using the Disk service. This can expose secrets such as secret_key_base and credentials, potentially leading to remote code execution or lateral movement. The issue arises because ImageMagick's coders are not constrained, enabling crafted files to invoke dangerous coders. Fixed versions introduce a security policy restricting risky coders and delegates.
A denial-of-service (DoS) vulnerability exists in Action Pack's Action Controller Live streaming feature due to improper handling of the response buffer's end-of-stream marker. When the client stops reading and the response queue is full, pushing the end-of-stream marker blocks and causes threads to wait indefinitely, potentially exhausting server threads. This affects applications using ActionController::Live streaming, including send_stream and Active Storage proxy mode for large files. Fixed versions 8.1.4.1 and 8.0.5.2 address this issue.
A vulnerability was determined in Linksys EA8100 1.0.3.216940. This issue affects the function SetRemoteSetting/SetUnsecuredWiFiWarning of the file ui_server.lua of the component JNAP API. This manipulation of the argument isEnabled/enabled causes missing authentication. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.
A vulnerability in Action Pack's Active Storage proxy mode can cause sensitive session information leakage when cookies are rotated or migrated using a hybrid serializer. This occurs because the session cookie is rewritten on cacheable responses despite session skipping options, potentially exposing user sessions via shared caches. The issue affects applications serving Active Storage files through proxy controllers with cookie rotation or hybrid serializer migration configured and using caches that store Set-Cookie headers on public responses. Fixed versions are available.
A cross-site scripting (XSS) vulnerability exists in the ActionView::Helpers::TextHelper#highlight method of the Action View component in Ruby on Rails. The vulnerability arises when a user-supplied phrase is substituted into a custom :highlighter string inside a quoted attribute without proper escaping, potentially allowing injection of malicious attributes and XSS. The default highlighter and block form are not affected. Fixed versions properly escape matched groups to prevent this issue.
A cross-site scripting (XSS) vulnerability exists in Action View's strip_tags method where it marks sanitized output as html_safe but does not encode quotes, allowing untrusted input rendered inside quoted HTML attributes to inject malicious attributes. This affects applications that use strip_tags output inside HTML attribute values, such as title or meta content attributes. The issue is fixed in versions 8.1.4.1 and 8.0.5.2 by encoding quotes in the output. Workarounds include passing strip_tags output through tag helpers that escape attribute values.
A cross-site scripting (XSS) vulnerability exists in the Action View text helpers `highlight` and `simple_format` when used with the HTML5 sanitizer in Rails applications using load_defaults 7.1 or later. The issue arises because Nokogiri before version 1.19.5 does not escape `<` and `>` characters inside attribute values, allowing potentially unsafe markup to be emitted as live HTML elements. This can lead to XSS when untrusted input is passed to these helpers. Fixed versions of Rails require rails-html-sanitizer 1.7.2 or later, which depends on Nokogiri 1.19.5 or newer that properly escapes these characters. Workarounds include upgrading Nokogiri or switching to the HTML4 sanitizer.
Active Storage's GCS service with the cache_control option configured signs direct-upload URLs using V4 signatures that do not cover the Content-Type header. This allows an attacker to upload objects with arbitrary Content-Type metadata, potentially serving malicious HTML content from the storage bucket. The vulnerability is fixed by reverting to V2 signing, which includes Content-Type and Content-MD5 in the signature. Fixed versions are 8.1.4.1 and 8.0.5.2.
A vulnerability in Action Pack's Parameters#each_key method allows a possible strong parameters bypass. When called with a block, each_key returns an internal hash that does not respond to permitted?, enabling mass assignment to accept unpermitted parameters. This can allow a remote unauthenticated attacker to set unauthorized attributes, such as authorization flags. The issue affects versions prior to 8.0.5.2 and between 8.1.0.beta1 and 8.1.4.1. Fixed versions 8.0.5.2 and 8.1.4.1 correct the behavior to return the Parameters instance, which enforces permission checks.
A memory denial-of-service vulnerability exists in Pillow's TIFF and EXIF IFD parsing due to overlapping tag data references. Crafted image files can cause Pillow to allocate memory many times larger than the file size during parsing, leading to process crashes or stalls. This affects TIFF, JPEG, PNG, WebP, and MPO images. The vulnerability has been present since Pillow 1.0 and is fixed in version 13.0.0.
A heap buffer overflow vulnerability exists in Pillow when saving TIFF images using libtiff with certain metadata tags that override the image size. This can cause the encoder to read or write beyond the allocated buffer, potentially leading to memory disclosure or process crashes. The flaw arises because Pillow merges image metadata tags such as ImageWidth, ImageLength, and SamplesPerPixel from EXIF or TIFF info without proper validation against the actual image size. This affects TIFF saving with compression enabled (other than raw) and has been fixed in Pillow version 13.0.0.
The hono framework's csrf() middleware does not validate requests with the Content-Type 'text/ping', which are sent by Chromium-based browsers' hyperlink auditing feature. This allows cross-origin POST requests with user cookies to bypass CSRF protections if the state-changing action does not depend on the request body. The vulnerability affects hono versions prior to 4.13.16.
The Hono framework's `validator('form')` function improperly validates `multipart/form-data` requests when the Content-Type header includes extra parameters beyond a single boundary parameter. This causes the validator to skip validation and pass an empty object to the callback, allowing form fields to bypass intended validation checks. The issue affects versions from 4.5.1 up to but not including 4.13.16 and is fixed in version 4.13.16.
### Summary
`mount()` and `app.mount()` remove the mount prefix from the request path and forward the rest to the mounted application. Two mistakes in that step let a crafted request reach a route of the mounted application that the outer application protects with path-scoped middleware, such as an authentication check on `/app/admin/*`. The outer application routes on the original path, so the middleware does not run.
### Details
1. **Dynamic prefix** (all affected versions): for a mount such as `/api/:tenant/*`, the prefix was removed by the length of the route pattern, not of the matched prefix. A request with a longer or shorter first segment is cut in the middle, so `/api/a/xxxxx/admin/secret` reaches the mounted application as `/admin/secret`.
2. **Re-normalization** (since 4.12.21): the forwarded path was built from the decoded request path and assigned to `url.pathname`, which turns a decoded backslash into `/` and collapses `..`. `/app/public%5C..%5Cadmin/secret` reaches the mounted application as `/admin/secret`.
The fix removes the prefix segment by segment from the raw pathname, using the matched parameter values for its length. Route patterns that cannot be handled safely now throw: duplicate parameter names and a wildcard inside the last segment such as `/assets*`. A trailing slash in an `app.mount()` prefix no longer removes an extra segment.
### Impact
An unauthenticated client can reach a route of a mounted application that the outer application protects with path-scoped middleware.
This affects applications that use `mount()` or `app.mount()` and rely on middleware registered on a sub-path inside the mount prefix for authentication or authorization.
### Workarounds
Register the authentication middleware inside the mounted application.
### Summary
RegExpRouter, which the default `SmartRouter` selects for most applications, skipped wildcard middleware in three cases, so a route handler ran without the middleware registered for it:
1. Middleware whose parameter is written with the explicit default pattern, such as `/api/:tenant{[^/]+}/admin/*`, was not applied to a route written as `/api/:tenant/admin/:id`. (since 4.13.0)
2. Middleware on `/admin/*` was not applied to a route registered on `/admin*` for paths under `/admin/`. (since 4.1.4)
3. For a path with an encoded line terminator (`%0A`, `%0D`, `%E2%80%A8`, `%E2%80%A9`), no wildcard pattern matched, so the request reached the not-found handler without any wildcard middleware. (since 4.4.0)
TrieRouter, LinearRouter and PatternRouter apply the middleware in all three cases.
### Details
RegExpRouter decides at registration time which wildcard middleware covers which route. In cases 1 and 2 it treated patterns that match the same requests as different ones. In case 3 the compiled wildcard did not match line terminators.
The fix derives the coverage from the structure of the registered paths and lets wildcards match line terminators. It also corrects other differences from the other routers (a wildcard in the middle of a path with parameters, duplicate middleware, middleware on static routes), and rejects custom patterns that can match the empty string, such as `{[0-9]*}`, with `UnsupportedPathError`. `PreparedRegExpRouter` data must be regenerated.
### Impact
An unauthenticated client can reach a route handler, or the not-found handler, without the authentication or authorization middleware registered on a wildcard path.
This affects applications that use RegExpRouter, directly or through the default `SmartRouter`, and rely on wildcard middleware for authentication or authorization.
### Workarounds
Use `new Hono({ router: new TrieRouter() })`.
### Summary
The `css` helper in `hono/css` escapes a `/` that follows `<` inside an interpolated value so that a value cannot close the `<style>` element. The check only looks inside each value. When the text before a value ends with `<`, whether that is the template itself or an earlier interpolated value, and the next value starts with `/`, the `/` is not escaped and the combined output contains an unescaped closing tag.
### Details
Interpolated string values are escaped one at a time before they are joined with the surrounding template text. The rule that neutralizes `</` therefore cannot see a `<` that belongs to the template. A template such as a `content` declaration that opens with a literal `<` and interpolates a string right after it produces a raw `</style>` when that string starts with `/style>`. During server-side rendering the `<Style />` element is closed early and the rest of the value is interpreted as HTML.
This issue arises only when `<` is the last character before an interpolation in a `css` template, either written in the template or supplied by a preceding value, and the interpolated value is controlled by a client.
### Impact
A client that controls such a value can inject HTML, including script, into the page rendered on the server.
This may lead to:
- Execution of attacker-controlled script in the browser of a user who views the page
- Exposure of information available to that page
This issue affects applications that interpolate untrusted strings into a `css` template immediately after a `<`, including two adjacent interpolations such as `${prefix}${name}` where both are untrusted. Other uses of the `css` helper are not affected.
### Workarounds
Do not interpolate untrusted values into `css` templates, or make sure the text before an interpolated value does not end with `<`.
### Summary
The StringMatcher/PathMatcher for `safe_regex` builds its RE2 as `^${regex}$` with no surrounding group. Because alternation has the lowest precedence, a pattern `"a|b|c"` compiles to `/^a|b|c$/` -- "starts with a" OR "contains b" OR "ends with c" instead of a full match of the whole value. Configurations with `safe_regex` matchers that use a regex alternation (a natural way to list methods or service identities) therefore apply partial string matches. This impacts route selection, xDS credentials, and RBAC.
### Details
`src/matcher.ts`: `SafeRegexValueMatcher` and `PathSafeRegexValueMatcher` both do
```ts
this.targetRegexImpl = new RE2(`^${targetRegex}$`, 'u');
```
and `apply()` returns `targetRegexImpl.test(value)`. With a top-level alternation the anchors bind only to the first/last branch.
https://github.com/grpc/grpc-node/blob/e742b11bd8039f3dbea4cd29afdf5d95a8ba6b92/packages/grpc-js-xds/src/matcher.ts#L59
https://github.com/grpc/grpc-node/blob/e742b11bd8039f3dbea4cd29afdf5d95a8ba6b92/packages/grpc-js-xds/src/matcher.ts#L232
`src/route.ts` (`getPredicateForStringMatcher` / `getPredicateForHeaderMatcher`) builds these for every `safe_regex` `StringMatcher`/`HeaderMatcher`, and src/rbac.ts uses them for RBAC `url_path` `permissions`/`principals`, `authenticated.principal_name` (mTLS SAN/CN), `requested_server_name` and `header rules`. So an ALLOW rule written with an alternation grants access to method names, certificate identities or header values that extend an intended one. DENY policies only become broader (fail-safe).
https://github.com/grpc/grpc-node/blob/e742b11bd8039f3dbea4cd29afdf5d95a8ba6b92/packages/grpc-js-xds/src/route.ts#L28
https://github.com/grpc/grpc-node/blob/e742b11bd8039f3dbea4cd29afdf5d95a8ba6b92/packages/grpc-js-xds/src/route.ts#L47
### Proof of concept
In a scratch directory:
```
npm init -y
npm i @grpc/grpc-js-xds@1.14.1 @grpc/grpc-js
node poc.cjs
```
`poc.cjs` calls the exported RBAC engine directly (the functions grpc-js uses to make the authorization decision); no server or network:
```js
const { parseConfig } = require('@grpc/grpc-js-xds/build/src/rbac.js')
const { SafeRegexValueMatcher } = require('@grpc/grpc-js-xds/build/src/matcher.js')
const { Metadata } = require('@grpc/grpc-js')
console.log(new SafeRegexValueMatcher('admin|editor').toString()) // SafeRegex(/^admin|editor$/u)
const sr = regex => ({ match_pattern: 'safe_regex', safe_regex: { regex } })
const info = urlPath => ({ urlPath, headers: new Metadata(), tls: true, peerCertificate: null,
destinationIp: '10.0.0.1', destinationPort: 443, sourceIp: '10.0.0.2' })
const g = parseConfig({ action: 'ALLOW', policies: { p: {
permissions: [{ rule: 'url_path', url_path: { path: sr('/acme.Users/GetUser|/acme.Users/ListUsers') } }],
principals: [{ identifier: 'any', any: true }] } } })
console.log('GetUser ', g.apply(info('/acme.Users/GetUser'))) // true (intended)
console.log('DeleteUser ', g.apply(info('/acme.Users/DeleteUser'))) // false (control)
console.log('GetUserSecrets', g.apply(info('/acme.Users/GetUserSecrets'))) // true <-- BYPASS
```
Observed (grpc-js-xds 1.14.1, grpc-js 1.14.6):
```
matcher "admin|editor" -> SafeRegex(/^admin|editor$/u);
apply("administrator")=true, apply("not-an-editor")=true
ALLOW url_path /acme.Users/GetUser|/acme.Users/ListUsers:
/acme.Users/GetUser -> ALLOWED (intended)
/acme.Users/DeleteUser -> denied (control)
/acme.Users/GetUserSecrets -> ALLOWED <-- bypass (policy intends deny)
control, same regex as (?:...|...): /acme.Users/GetUserSecrets -> denied
ALLOW authenticated principal_name spiffe://prod/ns/web/sa/frontend|...ops/sa/admin:
spiffe://prod/ns/web/sa/frontend-batch -> ALLOWED <-- bypass
```
### Impact
Users of `@grpc/grpc-js-xds` who are using `safe_regex` matchers with alternation for route selection, xDS credentials SAN matchers, or RBAC rules may see incorrectly permissive behavior.