Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update

It has been discovered that the extension is susceptible to SQL Injection when processing bounced emails.

libexpat before 2.7.5 allows an infinite loop while parsing DTD content.

Out-of-bounds Read in GitHub repository gpac/gpac prior to 2.2.2.

An out-of-bounds write of a zero byte exists in the X11 `display` interaction path that could lead to a crash.

A flaw was found in moodle before versions 3.7.1, 3.6.5, 3.5.7. Teachers in a quiz group could modify group overrides for other groups in the same quiz.

### Summary
This vulnerability allows a user to bypass any predefined hardcoded URL path or security anti-Localhost mechanism and perform an arbitrary GET request to any Host, Port and URL using a Webfinger Request.

### Details
The Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production.
The library attempts to prevent Localhost access using the following mechanism (/src/config.rs):
```rust
pub(crate) async fn verify_url_valid(&self, url: &Url) -> Result<(), Error> {
        match url.scheme() {
            "https" => {}
            "http" => {
                if !self.allow_http_urls {
                    return Err(Error::UrlVerificationError(
                        "Http urls are only allowed in debug mode",
                    ));
                }
            }
            _ => return Err(Error::UrlVerificationError("Invalid url scheme")),
        };

        // Urls which use our local domain are not a security risk, no further verification needed
        if self.is_local_url(url) {
            return Ok(());
        }

        if url.domain().is_none() {
            return Err(Error::UrlVerificationError("Url must have a domain"));
        }

        if url.domain() == Some("localhost") && !self.debug {
            return Err(Error::UrlVerificationError(
                "Localhost is only allowed in debug mode",
            ));
        }

        self.url_verifier.verify(url).await?;

        Ok(())
    }
```
There are multiple issues with the current anti-Localhost implementation: 

1. It does not resolve the domain address supplied by the user.
2. The Localhost check is using only a simple comparison method while ignoring more complex malicious tampering attempts.
3. It filters only localhost domains, without any regard for alternative local IP domains or other sensitive domains, such internal network or cloud metadata domains.

We can reach the verify_url_valid function while sending a Webfinger request to lookup a user’s account (/src/fetch/webfinger.rs):

```rust
pub async fn webfinger_resolve_actor<T: Clone, Kind>(
    identifier: &str,
    data: &Data<T>,
) -> Result<Kind, <Kind as Object>::Error>
where
    Kind: Object + Actor + Send + 'static + Object<DataType = T>,
    for<'de2> <Kind as Object>::Kind: serde::Deserialize<'de2>,
    <Kind as Object>::Error: From<crate::error::Error> + Send + Sync + Display,
{
    let (_, domain) = identifier
        .splitn(2, '@')
        .collect_tuple()
        .ok_or(WebFingerError::WrongFormat.into_crate_error())?;
    let protocol = if data.config.debug { "http" } else { "https" };
    let fetch_url =
        format!("{protocol}://{domain}/.well-known/webfinger?resource=acct:{identifier}");
    debug!("Fetching webfinger url: {}", &fetch_url);

    let res: Webfinger = fetch_object_http_with_accept(
        &Url::parse(&fetch_url).map_err(Error::UrlParse)?,
        data,
        &WEBFINGER_CONTENT_TYPE,
    )
    .await?
    .object;

    debug_assert_eq!(res.subject, format!("acct:{identifier}"));
    let links: Vec<Url> = res
        .links
        .iter()
        .filter(|link| {
            if let Some(type_) = &link.kind {
                type_.starts_with("application/")
            } else {
                false
            }
        })
        .filter_map(|l| l.href.clone())
        .collect();

    for l in links {
        let object = ObjectId::<Kind>::from(l).dereference(data).await;
        match object {
            Ok(obj) => return Ok(obj),
            Err(error) => debug!(%error, "Failed to dereference link"),
        }
    }
    Err(WebFingerError::NoValidLink.into_crate_error().into())
}
```

The Webfinger logic takes the user account from the GET parameter “resource” and sinks the domain directly into the hardcoded Webfinger URL (“{protocol}://{domain}/.well-known/webfinger?resource=acct:{identifier}”) without any additional checks.
Afterwards the user domain input will pass into the “fetch_object_http_with_accept” function and finally into the security check on “verify_url_valid” function, again, without any form of sanitizing or input validation.
An adversary can cause unwanted behaviours using multiple techniques:

1. **_Gaining control over the query’s path:_**
An adversary can manipulate the Webfinger hard-coded URL, gaining full control over the GET request domain, path and port by submitting malicious input like: hacker@hacker_host:1337/hacker_path?hacker_param#, which in turn will result in the following string:
http[s]://hacker_host:1337/hacker_path?hacker_param#/.well-known/webfinger?resource=acct:{identifier}, directing the URL into another domain and path without any issues as the hash character renders the rest of the URL path unrecognized by the webserver.

2. **_Bypassing the domain’s restriction using DNS resolving mechanism:_**
An adversary can manipulate the security check and force it to look for internal services regardless the Localhost check by using a domain name that resolves into a local IP (such as: localh.st, for example), as the security check does not verify the resolved IP at all - any service under the Localhost domain can be reached.

3. _**Bypassing the domain’s restriction using official Fully Qualified Domain Names (FQDNs):**_
In the official DNS specifications, a fully qualified domain name actually should end with a dot.
While most of the time a domain name is presented without any trailing dot, the resolver will assume it exists, however - it is still possible to use a domain name with a trailing dot which will resolve correctly.
As the Localhost check is mainly a simple comparison check - if we register a “hacker@localhost.” domain it will pass the test as “localhost” is not equal to “localhost.”, however the domain will be valid (Using this mechanism it is also possible to bypass any domain blocklist mechanism).


### PoC

1. Activate a local HTTP server listening to port 1234 with a “secret.txt” file:
`python3 -m http.server 1234`
2. Open the “main.rs” file inside the “example” folder on the activitypub-federated-rust project, and modify the “beta@localhost” string into “hacker@localh.st:1234/secret.txt?something=1#”.
3. Run the example using the following command:
`cargo run --example local_federation axum`
4. View the console of the Python’s HTTP server and see that a request for a “secret.txt” file was performed.

This proves that we can redirect the URL to any domain and path we choose.
Now on the next steps we will prove that the security checks of Localhost and blocked domains can be easily bypassed (both checks use the same comparison mechanism).

1. Now open the “instance.rs” file inside the “example” folder and view that the domain “malicious.com” is blocked (you can switch it to any desired domain address).
2. Change the same “beta@localhost” string into “hacker@malicious.com” and run the example command to see that the malicious domain blocking mechanism is working as expected.
3. Now change the “hacker@malicious.com” string into  “hacker@malicious.com.” string and re-initiate the example, view now that the check passed successfully.
4. You can combine both methods on “localhost.” domain (or any other domain) to verify that the FQDNs resolving is indeed successful.


### Impact
Due to this issue, any user can cause the server to send GET requests with controlled path and port in an attempt to query services running on the instance’s host, and attempt to execute a Blind-SSRF gadget in hope of targeting a known vulnerable local service running on the victim’s machine.

### Fix Suggestion
Modify the domain validation mechanism and implement the following checks:

1. Resolve the domain and validate it is not using any invalid IP address (internal, or cloud metadata IPs) using regexes of both IPv4 and IPv6 addresses.
For Implementation example of a good SSRF prevention practice you can review a similiar project such as “Fedify” (https://github.com/dahlia/fedify/blob/main/src/runtime/url.ts) which handles external URL resource correctly.
Note that it is still needed to remove unwanted characters from the URL. 
2. Filter the user’s input for any unwanted characters that should not be present on a domain name, such as #,?,/, etc.
3. Perform checks that make sure the desired request path is the executed path with the same port.
4. Disable automatic HTTP redirect follows on the implemented client, as redirects can be used for security mechanisms circumvention.

Libgcrypt before 1.12.2 mishandles Dilithium signing. Writes to a static array lack a bounds check but do not use attacker-controlled data.

In Zammad 6.4.x before 6.4.2, SSRF can occur. Authenticated admin users can enable webhooks in Zammad, which are triggered as POST requests when certain conditions are met. If a webhook endpoint returned a redirect response, Zammad would follow it automatically with another GET request. This could be abused by an attacker to cause GET requests for example in the local network.

Cross-site Scripting (XSS) - Stored in GitHub repository pimcore/pimcore prior to 10.5.21.

In http-proxy-middleware before 2.0.8 and 3.x before 3.0.4, writeBody can be called twice because "else if" is not used.

Red Hat Security Advisory: zziplib security update

The ejs (aka Embedded JavaScript templates) package before 3.1.10 for Node.js lacks certain pollution protection.

Floating Point Comparison with Incorrect Operator in GitHub repository gpac/gpac prior to 2.3-DEV.

Red Hat Security Advisory: qemu-kvm-rhev security and bug fix update

A security bypass vulnerability was discovered in `@angular/common` when Server-Side Rendering (SSR) and hydration are enabled in applications using a hierarchical `HttpClient` configuration with `withRequestsMadeViaParent()`.

The `HttpTransferCache` utility optimizes hydration by caching outgoing HTTP requests performed during SSR and transferring the cached state to the client-side application via `TransferState` (serialized as JSON in `<script id="ng-state">`). Following the remediation of [CVE-2026-50170](https://github.com/angular/angular/security/advisories/GHSA-q6f4-qqrg-jv6x), `HttpTransferCache` automatically skips caching requests that contain authentication headers or credentials (`Authorization`, `Cookie`, `withCredentials`, etc.).

However, when a child `HttpClient` delegates to a parent client via `withRequestsMadeViaParent()`, the child's `TransferCache` interceptor evaluates whether the request is eligible for caching **before** delegating to the parent client's interceptor chain. 

If an outgoing request originates as anonymous from the child client, the child `TransferCache` marks the request as cacheable. When the request reaches a parent interceptor that injects sensitive authentication credentials (such as an `Authorization` header or API token), the parent `TransferCache` correctly skips caching the authenticated request. However, when the backend returns the private, authenticated response, the child `TransferCache` still stores the response in `TransferState` based on its initial pre-delegation evaluation.

### Impact

Successful exploitation allows sensitive, user-specific information belonging to an authenticated user to be leaked to unauthenticated or unauthorized users. This occurs when:

1. During SSR, a child `HttpClient` initiates an unauthenticated request that is subsequently authenticated by a parent interceptor.
2. The authenticated response body is cached into the SSR-rendered HTML page (`TransferState`).
3. The rendered HTML page is stored by a shared caching layer (e.g., CDN, edge cache, or reverse proxy) or served across user sessions.
4. Subsequent visitors requesting the same page receive the cached HTML containing the previous user's private data.

### Attack Preconditions & Vulnerable Configurations

An application is affected only if **all** of the following conditions are met:

* **SSR and Hydration Enabled:** The application uses Server-Side Rendering with hydration enabled (e.g., via `provideClientHydration()`).
* **Hierarchical `HttpClient` with Delegation:** The application configures a child `HttpClient` using `withRequestsMadeViaParent()`.
* **Parent-Level Authentication Injection:** Authentication credentials (such as `Authorization` headers, session cookies, or custom API tokens filtered via `withHttpTransferCacheOptions`) are attached by an interceptor in the **parent** injector chain rather than on the initial child request.
* **Shared HTML Caching:** The SSR HTML responses are cached by a shared caching layer (CDN, reverse proxy, or application-level HTML cache).

#### Vulnerable Code Pattern Example

```ts
// Parent Injector / Application Config
export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(
      // Parent interceptor attaches sensitive Authorization header
      withInterceptors([
        (req, next) => next(req.clone({ setHeaders: { Authorization: `Bearer ${getToken()}` } }))
      ])
    ),
  ],
};

// Child Injector / Feature or Component Config
const childClient = createEnvironmentInjector(
  [
    // Child delegates to parent; TransferCache evaluates req BEFORE parent auth interceptor runs
    provideHttpClient(withRequestsMadeViaParent()),
  ],
  parentInjector
).get(HttpClient);

// Request originates without auth headers -> marked cacheable by child TransferCache
childClient.get('/api/user/profile').subscribe();
```

### Patches

The issue is resolved by updating `@angular/common` to run root interceptors in the terminal request chain so that delegated clients leave inherited root interceptors to the parent chain, preventing duplicate execution and ensuring `HttpTransferCache` evaluates cache eligibility after parent request interceptors run.

* `22.1.1`
* `21.2.20`
* `20.3.28`

### Workarounds & Mitigations

For applications that cannot immediately upgrade to a patched version, use one of the following mitigations:

1. **Attach Credentials Before or Within the Child Client:** Ensure authentication headers (e.g., `Authorization`) are attached directly when constructing the request or via an interceptor configured directly on the child `HttpClient`, rather than relying solely on parent interceptors.
2. **Apply Explicit Cache Filters on the Child Client:** Configure `withHttpTransferCacheOptions` with a filter on the child client that explicitly excludes endpoints returning user-specific or sensitive data:
   ```ts
   provideClientHydration(
     withHttpTransferCacheOptions({
       filter: (req) => !req.url.includes('/api/private/'),
     })
   )
   ```
3. **Disable HTTP Transfer Cache for Sensitive Routes:** If specific SSR routes handle user-authenticated data, disable transfer caching for those requests or ensure the SSR response sets `Cache-Control: no-store` / `private` headers at your edge/CDN layer so personalized HTML is never shared.

### 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`:

```go
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`:

```go
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)

```bash
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:

```go
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:

```go
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**).

docker2aci <= 0.12.3 has an infinite loop when handling local images with cyclic dependency chain.

Red Hat Security Advisory: libarchive security update

CVE ID↕	Published↕	CVSS↓
RHSA-2026:8749	Apr 26, 2026	Medium 4
GHSA-hqm2-gwqf-r5g5	Sep 2, 2021	Medium 4
CVE-2026-32777	Mar 16, 2026	Medium 4
CVE-2023-5520	Oct 11, 2023	Medium 4
GHSA-mw3m-pqr2-qv7c	Mar 26, 2026	Medium 4
GHSA-92q5-2h76-vgmj	May 24, 2022	Medium 4
RHSA-2026:25238	Jun 17, 2026	Medium 4
GHSA-7723-35v7-qcxw	Feb 10, 2025	Medium 4
DEBIAN-CVE-2026-41990	Apr 23, 2026	Medium 4
CVE-2025-32358	Apr 5, 2025	Medium 4
CVE-2023-2327	Apr 27, 2023	Medium 4
CVE-2025-32996	Apr 15, 2025	Medium 4
RHSA-2019:2196	Sep 16, 2024	Medium 4
DEBIAN-CVE-2024-33883	Apr 28, 2024	Medium 4
CVE-2023-4720	Sep 1, 2023	Medium 4
RHSA-2017:1431	Sep 13, 2024	Medium 4
GHSA-p297-fm68-3q8c	Sep 10, 2026	Medium 4
GHSA-r48c-v28r-pf6v	May 8, 2026	Medium 4
CVE-2016-8579	Oct 28, 2016	Medium 4
RHSA-2025:9431	Jun 25, 2025	Medium 4

Know every vulnerability
before it knows you.

Medium CVE Vulnerabilities (CVSS 4–6.9) — DevGuard

Know every vulnerabilitybefore it knows you.

Medium CVE Vulnerabilities (CVSS 4–6.9) — DevGuard

Know every vulnerability
before it knows you.