CWE-820

Jenkins Convertigo Mobile Platform Plugin 1.1 and earlier uses static fields to store job configuration information, allowing attackers with Item/Configure permission to capture passwords of the jobs that will be configured.

Grafana is an open-source platform for monitoring and observability. Using public dashboards users can query multiple distinct data sources using mixed queries. However such query has a possibility of crashing a Grafana instance. The only feature that uses mixed queries at the moment is public dashboards, but it's also possible to cause this by calling the query API directly. This might enable malicious users to crash Grafana instances through that endpoint. Users may upgrade to version 9.4.12 and 9.5.3 to receive a fix.

Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability

LibJS in Ladybird before f5a6704 mishandles the freeing of the vector that arguments_list references, leading to a use-after-free, and allowing remote attackers to execute arbitrary code via a crafted .js file. NOTE: the GitHub README says "Ladybird is in a pre-alpha state, and only suitable for use by developers."

Missing synchronization in Windows Hyper-V allows an authorized attacker to deny service over an adjacent network.

Missing synchronization in Windows Hyper-V allows an authorized attacker to deny service over an adjacent network.

A vulnerability exists in RTU IEC 61850 client and server functionality that could impact the availability if renegotiation of an open IEC61850 TLS connection takes place in specific timing situations, when IEC61850 communication is active. Precondition is that IEC61850 as client or server are configured using TLS on RTU500 device. It affects the CMU the IEC61850 stack is configured on.

free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's BSF PUT /nbsf-management/v1/subscriptions/{subId} handler has an unsynchronized write on the global Subscriptions map. The handler first reads the map under RLock() via BSFContext.GetSubscription(subId), but if the subscription does not exist, ReplaceIndividualSubcription() writes back to the same map directly without taking the mutex (bsfContext.BsfSelf.Subscriptions[subId] = subscription). Under concurrent authenticated PUT load, one goroutine can read while another writes the map, which causes the Go runtime to abort the process with fatal error: concurrent map read and map write (Go runtime panics that come from concurrent map access bypass recover() and terminate the process). The BSF container exits with code 2 -- the entire BSF SBI surface goes down until restart. This vulnerability is fixed in 4.2.2.

The on-endpoint Microsoft vulnerable driver blocklist is not fully synchronized with the online Microsoft recommended driver block rules. Some entries present on the online list have been excluded from the on-endpoint blocklist longer than the expected periodic monthly Windows updates. It is possible to fully synchronize the driver blocklist using WDAC policies. NOTE: The vendor explains that Windows Update provides a smaller, compatibility-focused driver blocklist for general users, while the full XML list is available for advanced users and organizations to customize at the risk of usability issues.

An issue exists in SoftIron HyperCloud where drive caddy removal and reinsertion without a reboot may erroneously cause the system to recognize the caddy as new media and wipe all data on the drives due to a missing synchronization flaw, which impacts data availability and integrity. This issue only impacts SoftIron HyperCloud "density" storage nodes running HyperCloud software versions 1.0 to before 2.0.3.

A Missing Synchronization vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS on ACX5448 and ACX710 allows an unauthenticated, adjacent attacker to cause a Denial-of-Service (DoS). If an interface flaps while the system gathers statistics on that interface, two processes simultaneously access a shared resource which leads to a PFE crash and restart. This issue affects Junos OS: * All versions before 20.4R3-S9, * 21.2 versions before 21.2R3-S5,  * 21.3 versions before 21.3R3-S5,  * 21.4 versions before 21.4R3-S4, * 22.1 versions before 22.1R3-S2, * 22.2 versions before 22.2R3-S2, * 22.3 versions before 22.3R2-S2, 22.3R3, * 22.4 versions before 22.4R2.

A Missing Synchronization vulnerability in the flow collector handler of Juniper Networks Junos OS Evolved on QFX Series allows an adjacent, unauthenticated attacker to cause a Denial-of-Service (DoS). When the reachability of an sFlow collector changes, the corresponding next-hop entry is updated. If this update occurs simultaneously with the sFlow thread accessing the next-hop data (which is outside the attackers control), it causes the evo-pfemand process to crash, impacting all traffic forwarding until the automatic process restart has completed. This issue affects Junos OS Evolved on QFX Series: * all 23.2 versions,  * 23.4 versions before 23.4R2-S7-EVO, * 24.2 versions before 24.2R2-S5-EVO, * 24.4 versions before 24.4R2-S3-EVO, * 25.2 versions before 25.2R2-EVO.

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation walk_s1() and kvm_walk_nested_s2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the respective walkers without taking kvm->srcu. Fix by acquiring kvm->srcu prior to the table walk in both instances.

In the Linux kernel, the following vulnerability has been resolved: mm/list_lru: drain before clearing xarray entry on reparent memcg_reparent_list_lrus() clears the dying memcg's xarray entry with xas_store(&xas, NULL) before reparenting its per-node lists into the parent. This opens a window where a concurrent list_lru_del() arriving for the dying memcg sees xa_load() == NULL, walks to the parent in lock_list_lru_of_memcg(), takes the parent's per-node lock, and calls list_del_init() on an item still physically linked on the dying memcg's list. If another in-flight thread holds the dying memcg's per-node lock at the same moment (another list_lru_del, or a list_lru_walk_one running an isolate callback), both threads modify ->next/->prev pointers on the same physical list under different locks. Adjacent items can corrupt each other's links. Fix it by reversing the order: reparent each per-node list and mark the child's list lru dead and then clear the xarray entry. Any concurrent list_lru op that finds the still-set xarray entry either takes the dying memcg's per-node lock (synchronizing with the drain) or sees LONG_MIN and walks to the parent, where the items now live.

Requires malware code to misuse the DDK kernel module IOCTL interface. Such code can use the interface in an unsupported way that allows subversion of the GPU to perform writes to arbitrary physical memory pages. The product utilises a shared resource in a concurrent manner but does not attempt to synchronise access to the resource.

### Summary: When Hoverfly is running in Diff mode, the `AddDiff()` function writes to the shared `responsesDiff` map without any synchronization (no mutex). When multiple proxy requests are processed concurrently (the normal case for any proxy), the concurrent map writes trigger Go's built-in race detector which causes a `fatal error: concurrent map read and map write`, immediately killing the entire Hoverfly process. This is trivially exploitable by sending multiple simultaneous requests. ### Details: **1. Unsynchronized map access in `AddDiff()` (`core/hoverfly_service.go:417-421`):** ```go func (hf *Hoverfly) AddDiff(requestView v2.SimpleRequestDefinitionView, diffReport v2.DiffReport) { if len(diffReport.DiffEntries) > 0 { diffs := hf.responsesDiff[requestView] // UNSYNCHRONIZED READ hf.responsesDiff[requestView] = append(diffs, diffReport) // UNSYNCHRONIZED WRITE } } ``` **2. This function is called from Diff mode processing, which runs concurrently per request (`core/modes/diff_mode.go`):** Each incoming proxy request is handled in its own goroutine by Go's `net/http` server. In Diff mode, each request calls `AddDiff()` after comparing the simulated and actual responses. With multiple concurrent requests, multiple goroutines write to the same map simultaneously. **3. Go's runtime detects concurrent map access and terminates the process:** Unlike data races on simple values (which produce undefined behavior silently), Go's map implementation includes a built-in concurrent access check. When two goroutines access the same map and at least one is writing, the runtime calls `fatal()` which is unrecoverable, it cannot be caught by `recover()`. **4. No mutex protection exists on `responsesDiff`:** The field is declared as a plain `map[v2.SimpleRequestDefinitionView][]v2.DiffReport` with no associated `sync.RWMutex`. Compare with `hf.state` which properly uses `sync.RWMutex` for its map access. ### Environment: - **Hoverfly version:** v1.12.7 - **Operating System:** macOS Darwin 25.4.0 - **Go version:** 1.26.2 - **Configuration:** Hoverfly in Diff mode (`PUT /api/v2/hoverfly/mode {"mode":"diff"}`) ### POC: **Step 1: Start Hoverfly and set Diff mode** ```bash ./hoverfly & sleep 2 # Set diff mode curl -X PUT http://localhost:8888/api/v2/hoverfly/mode \ -H "Content-Type: application/json" \ -d '{"mode": "diff"}' # Load a simulation for diff comparison curl -X PUT http://localhost:8888/api/v2/simulation \ -H "Content-Type: application/json" \ -d '{ "data": { "pairs": [{ "request": {"path": [{"matcher": "glob", "value": "*"}]}, "response": {"status": 200, "body": "expected"} }], "globalActions": {"delays": [], "delaysLogNormal": []} }, "meta": {"schemaVersion": "v5.2"} }' ``` **Step 2: Send concurrent requests to trigger the race** ```bash # Send 50 concurrent requests, race condition triggers within seconds for i in $(seq 1 50); do curl -s -x http://localhost:8500 "http://httpbin.org/get?id=$i" & done wait ``` **Step 3: Observe the crash** ```bash # Check if process is still running pgrep -f hoverfly ``` **crash output on Hoverfly v1.12.7:** ``` fatal error: concurrent map read and map write goroutine 892 [running]: github.com/SpectoLabs/hoverfly/core.(*Hoverfly).AddDiff(...) /core/hoverfly_service.go:419 github.com/SpectoLabs/hoverfly/core/modes.(*DiffMode).Process(...) ``` The process crashes with ~50 concurrent requests. In production with real traffic, it crashes almost immediately. ### Impact: - **Full denial of service:** The process terminates immediately and cannot be recovered without a restart - **Trivial exploitation:** Any attacker with proxy access can trigger this by sending multiple concurrent requests - **No admin API access required:** Only proxy port access is needed to trigger the crash - **Unrecoverable:** `fatal error` in Go cannot be caught by `recover()` — the process is unconditionally killed - **Affects all Diff mode users:** Any team using Diff mode for API comparison testing is vulnerable