Skip to content

Update module github.com/modelcontextprotocol/registry to v1.7.7 [SECURITY]#5230

Open
renovate[bot] wants to merge 1 commit intomainfrom
renovate/go-github.com-modelcontextprotocol-registry-vulnerability
Open

Update module github.com/modelcontextprotocol/registry to v1.7.7 [SECURITY]#5230
renovate[bot] wants to merge 1 commit intomainfrom
renovate/go-github.com-modelcontextprotocol-registry-vulnerability

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate Bot commented May 8, 2026

This PR contains the following updates:

Package Change Age Confidence
github.com/modelcontextprotocol/registry v1.7.0 → v1.7.7 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

MCP Registry has open redirect via protocol-relative path in trailing-slash middleware

CVE-2026-44427 / GHSA-v8vw-gw5j-w7m6

More information

Details

Summary

The TrailingSlashMiddleware in internal/api/server.go is vulnerable to an open redirect attack. An attacker can craft a URL with a protocol-relative path (e.g., //evil.com/) that, after trailing slash removal, results in a Location header of //evil.com — which browsers interpret as an absolute URL to an external domain.

Details

The TrailingSlashMiddleware strips trailing slashes from request paths and issues a 308 Permanent Redirect to the cleaned path. However, it does not validate or sanitize the resulting path before using it as the redirect target.

When a request is made with a path like //evil.com/, the middleware processes it as follows:

PoC
  1. Start the registry server locally or identify a deployed instance
  2. Send a request with a double-slash path followed by an external domain:
    curl -v https://<registry-host>//evil.com/
image 3. Observe the 308 Permanent Redirect response with Location: //evil.com: 4. When accessed in a browser, the user is redirected to https://evil.com
Impact

Phishing: Attackers can abuse the trusted registry domain to redirect users to credential-harvesting pages
Malware distribution: Redirect users to sites serving malicious downloads
Trust abuse: Links originating from the official MCP Registry domain carry implicit trust

Severity

  • CVSS Score: 5.7 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

MCP Registry's GitHub OIDC tokens are replayable across registry deployments due to shared audience

CVE-2026-44428 / GHSA-95c3-6vvw-4mrq

More information

Details

[SECURITY] registry_001 Vulnerability Report

While analyzing the code logic, an area that may lead to unintended behavior under specific conditions was discovered.

Overview
  • Verified Version: c5c4b9e8890dd5754bee889b2f1417f4fe3b5ce5
  • Vulnerability Type: Authentication bypass via cross-registry OIDC token replay
  • Affected Location: cmd/publisher/commands/login.go:67-105,130-135,199-224; cmd/publisher/auth/github-oidc.go:24-38,58-75,108-165; internal/api/handlers/v0/auth/github_oidc.go:75-135,229-277,280-296
  • Trigger Scenario: a workflow invokes mcp-publisher login github-oidc --registry <other-registry> (or equivalent publish flow) and the publisher still requests a GitHub Actions ID token with the shared audience mcp-registry; any other registry deployment running this code can replay that token to its own /v0/auth/github-oidc endpoint and mint a publish-capable registry JWT for the same GitHub owner namespace.
Root Cause

The client-side and server-side GitHub OIDC flow is bound only to a global audience string, not to the specific registry instance being targeted. On the client side, the publisher always appends audience=mcp-registry when requesting the GitHub Actions ID token, regardless of the selected --registry URL. On the server side, the exchange endpoint validates only that same fixed audience and then derives publish permissions directly from repository_owner. As a result, a token legitimately obtained while interacting with one registry deployment remains acceptable to any other deployment that shares the same code and audience string.

Source-to-Sink Chain
  1. Source
    cmd/publisher/commands/login.go:67-105,130-135,199-224 parses the user-controlled --registry flag into flags.RegistryURL, creates a GitHubOIDCProvider, and calls authProvider.GetToken(ctx) for the chosen authentication method.
  2. Propagation
    cmd/publisher/auth/github-oidc.go:24-38 obtains an OIDC token and immediately exchanges it against the selected registry URL.
    cmd/publisher/auth/github-oidc.go:58-75 builds exchangeURL := o.registryURL + "/v0/auth/github-oidc" and posts the GitHub token to whichever registry instance was selected.
    cmd/publisher/auth/github-oidc.go:108-165 constructs fullURL := requestURL + "&audience=mcp-registry" and therefore requests the same audience for every registry deployment.
  3. Sink
    internal/api/handlers/v0/auth/github_oidc.go:75-135 validates only the shared audience value passed into ValidateToken.
    internal/api/handlers/v0/auth/github_oidc.go:254-277 calls h.validator.ValidateToken(ctx, oidcToken, "mcp-registry") and, on success, signs a new registry JWT.
    internal/api/handlers/v0/auth/github_oidc.go:280-296 converts claims.RepositoryOwner into the publish permission pattern io.github.<owner>/*, which is then embedded into the new registry JWT.
Exploitation Preconditions
  1. The victim uses the GitHub Actions OIDC publishing path.
  2. The victim workflow targets another registry deployment first, such as staging, self-hosted infrastructure, or an attacker-controlled registry URL.
  3. The receiving registry deployment can observe the posted OIDC token and replay it before expiry to another registry deployment running the same shared audience configuration.
Risk

This breaks deployment isolation between registry instances. A token issued for one registry interaction can be replayed across trust boundaries, allowing one deployment to impersonate the same GitHub owner identity on another deployment.

Impact

An attacker-controlled or compromised registry deployment can mint a valid registry JWT on another deployment and inherit publish permissions for the victim GitHub owner namespace. In practical terms, this enables unauthorized publication or update actions for names such as io.github.<owner>/* on the victim registry instance.

Remediation
  1. Replace the shared audience string with a registry-specific audience, such as a deployment-specific client ID or origin-derived identifier.
  2. Ensure the publisher requests the audience that matches the exact registry instance it is targeting, and ensure the server validates that same instance-specific value.
  3. Consider binding the exchange to additional deployment-specific claims so that a token captured by one registry cannot be replayed on another.
  4. Add regression tests that cover cross-deployment replay attempts between different registry URLs.

Severity

  • CVSS Score: 2.1 / 10 (Low)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

MCP Registry vulnerable to stored XSS in catalogue UI via attribute-quote breakout in publisher-controlled websiteUrl

CVE-2026-44429 / GHSA-rqv2-m695-f8j4

More information

Details

Summary

The public catalogue UI served at GET / (file internal/api/handlers/v0/ui_index.html) is vulnerable to stored cross-site scripting via the server.websiteUrl field of any published server.json. Server-side validation in internal/validators/validators.go (validateWebsiteURL) only checks that the URL parses, is absolute, and uses the https scheme; it does not reject quote characters. Client-side, the value is interpolated into a double-quoted href attribute via innerHTML, using a homegrown escapeHtml helper that performs the standard textContent → innerHTML round-trip. Per the HTML serialisation algorithm, that round-trip encodes only &, <, > and U+00A0 inside text nodes — it does not encode " or '. A literal " in websiteUrl therefore breaks out of the href attribute, allowing arbitrary on* event handlers to be appended to the same <a> element. The Content-Security-Policy on / is script-src 'self' 'unsafe-inline' https://cdn.tailwindcss.com, so the injected event handlers execute.

Any user able to obtain a publish token (e.g. via POST /v0/auth/github-at with their own GitHub account, or POST /v0/auth/none on a deployment that has anonymous auth enabled) can plant a poisoned record visible to every visitor of the registry homepage.

Affected component
  • Validator: internal/validators/validators.go — validateWebsiteURL (lines 153–199)
  • Sink: internal/api/handlers/v0/ui_index.html — toggleDetails(card, item) at line 432, the href attribute built around escapeHtml(server.websiteUrl)
  • Helper: escapeHtml defined at internal/api/handlers/v0/ui_index.html lines 494–498
Proof of concept

  1. Obtain a Registry JWT for any namespace you control (a GitHub OAuth exchange against a throwaway account suffices):

    TOKEN=$(curl -sS -X POST https://registry.modelcontextprotocol.io/v0/auth/github-at \
     -H 'Content-Type: application/json' \
     -d '{"github_token":"<gh-pat>"}' | jq -r .registry_token)

  2. Publish a server with a poisoned websiteUrl. The literal " is preserved end-to-end:

    curl -sS -X POST https://registry.modelcontextprotocol.io/v0/publish \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  --data-binary @&#8203;- <<'EOF'
{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-09-29/server.schema.json",
  "name":  "io.github.<your-account>/xss-poc",
  "version": "0.0.1",
  "description": "hover the website link",
  "websiteUrl": "https://example.com/\"onmouseover=alert(document.domain)//"
}
EOF

  3. Visit https://registry.modelcontextprotocol.io/, search for xss-poc, click the card to expand it, then hover the Website link in the details panel. The injected onmouseover fires and alert(document.domain) runs on the registry.modelcontextprotocol.io origin.

Why server-side validation does not catch this

Go's net/url.Parse accepts literal " in the path component:

input="https://example.com/\"onmouseover=alert(1)//"  IsAbs=true  Scheme="https"  Path="/\"onmouseover=alert(1)//"

Neither the Huma format:"uri" annotation nor validateWebsiteURL's scheme/IsAbs triplet rejects this string. The architecture's existing protection — repository.url is regex-locked to ^https?://(www\.)?github\.com/[\w.-]+/[\w.-]+/?$ and therefore cannot contain quotes — does not extend to websiteUrl, which has no allowlist.

Why client-side escapeHtml does not catch this
function escapeHtml(text) {
    const div = document.createElement('div');
    div.textContent = text;
    return div.innerHTML;
}

Per the HTML5 spec (§13.3 Serialising HTML fragments), the only characters encoded inside the text content of an element are &, <, >, and U+00A0. " and ' are not encoded because in a text-content context they are not special. The helper is therefore safe in element-text contexts (where it is correctly used for name, version, description, etc.) but unsafe inside an attribute value, which is precisely where it is invoked for href on lines 432 and 426.

Impact
  • Stored XSS on the official MCP Registry homepage. The malicious entry sits in the public catalogue alongside legitimate ones; any user expanding the entry triggers the payload.
  • Because the page is served on the official registry.modelcontextprotocol.io origin, the injected script can:
    • Read and overwrite localStorage (baseUrl, customUrl), pinning the user's subsequent reads to an attacker-controlled "Custom" base URL.
    • Issue any same-origin or cross-origin XHR (connect-src * is granted).
    • Phish for Registry JWTs by injecting fake auth flows on the trusted origin.
  • The CSP script-src 'self' 'unsafe-inline' https://cdn.tailwindcss.com does not block this because 'unsafe-inline' permits inline event-handler attributes.
Suggested remediation (any one suffices)
  1. Replace the homegrown escapeHtml with an attribute-safe encoder that also escapes ", ', backtick, and = — the OWASP HTML attribute-encoding rule.
  2. Avoid building the href via string templates. Use setAttribute('href', value) instead — setAttribute is not subject to HTML tokenisation, so no breakout is possible.
  3. Tighten validateWebsiteURL to reject any URL whose raw bytes contain ", ', <, >, , \t, or \n, or — conservatively — store the canonical re-serialised form (parsedURL.String() percent-encodes such characters in the path).
  4. Drop 'unsafe-inline' from script-src after auditing the inline scripts on the page.

Approach (3) is the smallest server-side change and immediately neutralises the exploit for any new publishes; approaches (1) or (2) close the class of bug at the sink so future fields with similar patterns are safe by default.

Severity

  • CVSS Score: 5.1 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:N/SI:L/SA:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

MCP Registry has an unauthenticated SSRF: HTTP namespace verification dials 6to4 / NAT64 / site-local IPv6 addresses, bypassing private-address allowlist

CVE-2026-44430 / GHSA-r48c-v28r-pf6v

More information

Details

Summary

The Registry's HTTP-based namespace verification (POST /v0/auth/http, POST /v0.1/auth/http) uses safeDialContext (internal/api/handlers/v0/auth/http.go:67-110) to refuse dialling private/internal addresses when fetching the well-known public-key file from a publisher-supplied domain. The blocklist (isBlockedIP, lines 125-133) relies entirely on Go stdlib's IsLoopback / IsPrivate / IsLinkLocalUnicast / IsMulticast / IsUnspecified plus a manual CGNAT range. None of these cover IPv6 6to4 (2002::/16), NAT64 (64:ff9b::/96 and 64:ff9b:1::/48 per RFC 8215), or deprecated site-local (fec0::/10) — all of which encode arbitrary IPv4 in the address bits and tunnel to RFC1918 / cloud-metadata services on dual-stack / NAT64-enabled hosts.

This is the same CWE-918 SSRF class fixed in GHSA-56c3-vfp2-5qqj on czlonkowski/n8n-mcp (CVSS 8.5 HIGH). The remediation pattern is identical: extend the blocklist with the IPv6 prefix families that embed IPv4.

The endpoint is unauthenticated — it is the login flow itself — so attack complexity is low aside from the host-level routing dependency.

Affected: latest main HEAD 23f4fda and current production v1.7.6 deployment at https://registry.modelcontextprotocol.io/v0/auth/http.

Details
Vulnerable code

internal/api/handlers/v0/auth/http.go:125-133:

func isBlockedIP(ip net.IP) bool {
    if ip == nil {
        return true
    }
    return ip.IsLoopback() || ip.IsPrivate() ||
        ip.IsLinkLocalUnicast() || ip.IsMulticast() ||
        ip.IsUnspecified() ||
        cgnatRange.Contains(ip)
}

Per Go source (src/net/ip.go), the relevant stdlib helpers cover:

Helper IPv6 coverage
IsLoopback ::1, IPv4-mapped of 127/8 (via To4() fast-path)
IsPrivate ULA fc00::/7 only — ip[0]&0xfe == 0xfc
IsLinkLocalUnicast fe80::/10 only — ip[1]&0xc0 == 0x80 (NOT fec0::/10 which is 0xc0)
IsMulticast ff00::/8
IsUnspecified ::

The Registry's blocklist therefore does not cover:

Prefix Defined in Why dangerous
2002::/16 RFC 3056 (6to4) Bits 16-47 embed an arbitrary IPv4 address. 2002:a9fe:a9fe:: is the 6to4 encoding of 169.254.169.254 (AWS / Azure metadata). 2002:0a00:0001:: encodes 10.0.0.1. On hosts with 6to4 routing or any explicit 2002::/16 route, the dial reaches the embedded IPv4.
64:ff9b::/96 RFC 6052 (NAT64 well-known prefix) Low 32 bits embed an IPv4 address. 64:ff9b::a9fe:a9fe translates to 169.254.169.254 on any NAT64-enabled network — which is the default in IPv6-only GKE node pools, AWS IPv6-only EC2, Azure IPv6 VMs with NAT64, and DNS64/NAT64 corporate networks.
64:ff9b:1::/48 RFC 8215 (local-use NAT64) Same tunnelling concern, intended for operator-defined NAT64.
fec0::/10 RFC 3879 (deprecated site-local) Some BSD / older Linux stacks still honour these for routing into site-local internal networks.

safeDialContext resolves DNS once and dials by IP (good — pins against rebinding TOCTOU), but the IP-allowlist gate is the security boundary, and that gate is incomplete.

Exposure surface

POST /v0/auth/http (and POST /v0.1/auth/http) is registered in internal/api/handlers/v0/auth/http.go:197-218 and routed unauthenticated in internal/api/router/v0.go:24,39:

huma.Register(api, huma.Operation{
    OperationID: "exchange-http-token...",
    Method:      http.MethodPost,
    Path:        pathPrefix + "/auth/http",
    Summary:     "Exchange HTTP signature for Registry JWT",
    ...
}, func(ctx context.Context, input *HTTPTokenExchangeInput) (...) {
    response, err := handler.ExchangeToken(ctx, input.Body.Domain, ...)
    ...
})

The handler builds https://<attacker-domain>/.well-known/mcp-registry-auth (line 143) and dials via the safeDialContext-equipped client. The domain parameter is taken verbatim from the unauthenticated POST body.

Critical order-of-operations confirmation in CoreAuthHandler.ExchangeToken (internal/api/handlers/v0/auth/common.go:246-265):

  1. ValidateDomainAndTimestamp(domain, timestamp) — domain format check (no IP literal, must contain dot)
  2. DecodeAndValidateSignature(signedTimestamp) — hex decode
  3. keyFetcher(ctx, domain) ← SSRF dial happens here
  4. VerifySignatureWithKeys(...) ← only AFTER fetch

So the SSRF dial fires before any signature verification. Attacker needs only a valid RFC3339 timestamp (±15s window) and any hex string for signedTimestamp.

PoC

Tested against main HEAD 23f4fda (make dev-compose boots Registry on localhost:8080).

Step 1 — Set up attacker DNS

Configure attacker.example with the AAAA records:

attacker-6to4.example.       AAAA  2002:a9fe:a9fe::         ; 6to4 -> 169.254.169.254
attacker-nat64.example.      AAAA  64:ff9b::a9fe:a9fe       ; NAT64 -> 169.254.169.254
attacker-rfc1918.example.    AAAA  64:ff9b::a00:0001        ; NAT64 -> 10.0.0.1

(Equivalent free options: a domain on Cloudflare with manual AAAA, or a requestbin-style service with custom DNS.)

Step 2 — Trigger the dial (no credentials required)
curl -i https://registry.modelcontextprotocol.io/v0/auth/http \
  -H 'Content-Type: application/json' \
  -d "{\"domain\":\"attacker-nat64.example\",\"timestamp\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",\"signedTimestamp\":\"00\"}"

Timestamp need only be within ±15s of server clock. signedTimestamp is any hex string — it is decoded but only verified AFTER FetchKey has already dialled.

Step 3 — Observe

On a NAT64-enabled host (default in IPv6-only GKE / AWS IPv6 nodes / Cloudflare WARP), the server-side dial reaches 169.254.169.254:443. Tcpdump on the registry host confirms the outbound TLS handshake to the embedded IPv4. Where 169.254.169.254 listens on a TLS port (most cloud metadata services do not, but kube-apiserver, internal admin panels, and bespoke IPv4 services do), the connection completes and the response (limited to 4 KiB by MaxKeyResponseSize) is consumed as a key candidate.

For hosts without 6to4 / NAT64 routing, the dial fails with no route to host rather than refusing to connect to private or loopback address — proving the gate did not block. The differential error message provides a blind-SSRF oracle for probing internal services for existence / TLS port reachability.

Expected behaviour after fix

isBlockedIP should return true for any IPv6 address in the prefix families listed above, mirroring the n8n-mcp isPrivateOrMappedIpv6 helper (GHSA-56c3-vfp2-5qqj patch). Reference implementation:

func isBlockedIPv6Prefix(ip net.IP) bool {
    v6 := ip.To16()
    if v6 == nil || ip.To4() != nil {
        return false
    }
    // 6to4 (2002::/16)
    if v6[0] == 0x20 && v6[1] == 0x02 {
        return true
    }
    // NAT64 well-known 64:ff9b::/96
    if v6[0] == 0x00 && v6[1] == 0x64 && v6[2] == 0xff && v6[3] == 0x9b &&
       v6[4] == 0 && v6[5] == 0 && v6[6] == 0 && v6[7] == 0 {
        return true
    }
    // NAT64 RFC 8215 local-use 64:ff9b:1::/48
    if v6[0] == 0x00 && v6[1] == 0x64 && v6[2] == 0xff && v6[3] == 0x9b &&
       v6[4] == 0x00 && v6[5] == 0x01 {
        return true
    }
    // Site-local fec0::/10 (deprecated, RFC 3879 -- still honoured by some stacks)
    if v6[0] == 0xfe && (v6[1]&0xc0) == 0xc0 {
        return true
    }
    return false
}

Then extend the call site:

return ip.IsLoopback() || ip.IsPrivate() ||
    ip.IsLinkLocalUnicast() || ip.IsMulticast() ||
    ip.IsUnspecified() ||
    cgnatRange.Contains(ip) ||
    isBlockedIPv6Prefix(ip)

A regression test fixture should set up a stub resolver returning each of the four prefix families and assert that safeDialContext returns the "private/loopback" error before any dial.

Impact

CWE: CWE-918 Server-Side Request Forgery (consistent with parent precedent GHSA-56c3-vfp2-5qqj).

CVSS:3.1: matching the n8n-mcp precedent (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N ~= 8.5 HIGH). AC = High because exploitation depends on the registry host having NAT64 or 6to4 routing — the default on IPv6-only and dual-stack cloud network plans (GKE IPv6, AWS IPv6-only EC2, Azure IPv6 VMs with NAT64) but not on plain-IPv4 deployments. Privileges = None (the endpoint is the login flow itself).

For the official https://registry.modelcontextprotocol.io deployment specifically, this lets an unauthenticated attacker reach any IPv4 address that is routable from the registry's outbound interface — including AWS / GCP / Azure metadata services if hosted on a cloud VM with metadata enabled, internal Kubernetes API servers, internal admin panels, etc. The 4 KiB response cap (MaxKeyResponseSize) limits exfiltrated content per request but does not prevent fingerprinting / oracle attacks (status-code differential, response-length differential).

Self-hosters running the registry on dual-stack / IPv6-only infrastructure are equally exposed.

Why this slipped past PR #​1227

The April 29 hardening batch (commit 1201cbd, "security: fix open redirect and add small hardening") explicitly added safeDialContext to block "loopback, RFC1918, link-local, multicast, CGNAT, or IP-literal/single-label" addresses. The author correctly identified the IPv4 attack surface and the link-local cloud-metadata vector, but composed the blocklist from Go's per-class stdlib helpers — which collectively miss the IPv6 prefix families that embed IPv4. The same gap was caught and fixed in n8n-mcp (GHSA-56c3-vfp2-5qqj). No commits in git log --since=2026-03-01 internal/api/handlers/v0/auth/http.go reference 6to4 / NAT64 / site-local.

Credit

Reported by Matteo Panzeri (GitHub: matte1782).

Severity

  • CVSS Score: 6.3 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

modelcontextprotocol/registry (github.com/modelcontextprotocol/registry)

v1.7.7

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/registry@v1.7.6...v1.7.7

v1.7.6

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/registry@v1.7.5...v1.7.6

v1.7.5

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/registry@v1.7.4...v1.7.5

v1.7.4

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/registry@v1.7.3...v1.7.4

v1.7.3

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/registry@v1.7.2...v1.7.3

v1.7.2

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/registry@v1.7.1...v1.7.2

v1.7.1

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/registry@v1.7.0...v1.7.1

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • ""
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot added the dependencies Pull requests that update a dependency file label May 8, 2026
@renovate renovate Bot requested a review from JAORMX as a code owner May 8, 2026 17:22
@renovate renovate Bot added the dependencies Pull requests that update a dependency file label May 8, 2026
@github-actions github-actions Bot added the size/XS Extra small PR: < 100 lines changed label May 8, 2026
@codecov
Copy link
Copy Markdown

codecov Bot commented May 8, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 67.85%. Comparing base (e943660) to head (b775440).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files 
@@            Coverage Diff             @@
##             main    #5230      +/-   ##
==========================================
- Coverage   67.87%   67.85%   -0.02%     
==========================================
  Files         610      610              
  Lines       62405    62481      +76     
==========================================
+ Hits        42356    42399      +43     
- Misses      16869    16900      +31     
- Partials     3180     3182       +2

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@JAORMX JAORMX Awaiting requested review from JAORMX JAORMX is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file size/XS Extra small PR: < 100 lines changed

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants