CVE-2026-109575 is a critical authentication bypass vulnerability in HAProxy Data Plane API Enterprise Edition versions 2.2.0 through 3.4.3. The flaw arises from a process-global authentication logic error that disables Basic authentication on shared internal request handlers when TLS CA and numeric TLS port are configured. This causes non-mutual TLS listeners such as HTTP and UNIX domain socket endpoints to fail open, allowing unauthenticated attackers to gain full administrative API access. Exploitation enables reading or replacing HAProxy configuration data without credentials. The issue is fixed in versions 3.4.4, 3.3.9, 3.2.17, 3.0.25, 2.9.29, and corresponding Enterprise Edition backports.
A Cross-Site Request Forgery (CSRF) vulnerability exists in the Patreon WordPress plugin 'patreon-connect' affecting versions up to 1.9.17. This vulnerability allows an attacker to perform unauthorized actions on behalf of an authenticated user. The vulnerability has a high severity with a CVSS score of 8.1.
Admidio versions 4.0.12 through 4.3.17 and 5.0.0 before 5.0.15 contain a reflected cross-site scripting (XSS) vulnerability in the system/redirect.php component. This vulnerability allows unauthenticated attackers to inject JavaScript code via the url GET parameter due to an incomplete fix of a previous vulnerability (CVE-2021-43810). The attack involves crafting a javascript: URL with a decoy http:// segment that bypasses validation and executes script in the context of the Admidio origin when a victim clicks the redirect link.
Admidio versions 4.3.2 through 4.3.17 and 5.0.0 before 5.0.15 have a broken access control vulnerability. This flaw allows role administrators to assign users to roles in organizations other than their own by submitting crafted requests with foreign role UUIDs. Exploiting this, attackers can gain privileged membership in other organizations, log in as those users, and modify user profiles.
CVE-2026-105412 is an SQL Injection vulnerability in Dassault Systèmes Tuleap Enterprise Edition versions 17.5-1 through 17.5-35. This flaw could allow an attacker with limited privileges to read the Tuleap database. The vulnerability has a high severity rating with a CVSS score of 7.1. No official patch or remediation details are provided in the available data.
CVE-2026-105411 is a high-severity authorization bypass vulnerability in Dassault Systèmes Tuleap Enterprise Edition versions 17.0-1 through 17.0-41 and 17.5-1 through 17.5-32. It allows an attacker with tracker administration rights on one tracker to update or delete fields of all trackers on the instance without proper authorization.
CVE-2026-105410 is a stored Cross-site Scripting (XSS) vulnerability in Dassault Systèmes Tuleap Enterprise Edition versions 17.0-1 through 17.0-41 and 17.5-1 through 17.5-32. This flaw allows an attacker to inject and execute arbitrary script code in the browser session of users. The vulnerability is classified as high severity with a CVSS score of 8.7, indicating significant impact on confidentiality and integrity. No information about available patches or vendor advisories is provided.
CVE-2026-105409 is a stored Cross-site Scripting (XSS) vulnerability in Dassault Systèmes Tuleap Enterprise Edition versions 17.0-1 through 17.0-41 and 17.5-1 through 17.5-32. This vulnerability allows an attacker to inject and execute arbitrary script code within the browser session of a user. The vulnerability is classified as CWE-79, indicating improper neutralization of input during web page generation. It has a high severity with a CVSS score of 8.7, reflecting its potential impact on confidentiality and integrity. No information about available patches or vendor advisories is provided. No known exploits in the wild have been reported.
CVE-2026-105408 is a stored Cross-site Scripting (XSS) vulnerability in Dassault Systèmes Tuleap Enterprise Edition versions from 17.0-1 through 17.0-41 and 17.5-1 through 17.5-32. This vulnerability allows an attacker to inject and execute arbitrary script code in the browser session of a user. It has a high severity rating with a CVSS score of 8.7, indicating significant impact on confidentiality and integrity if exploited.
Red Hat OpenStack Platform provides the facilities for building, deploying and monitoring a private or public infrastructure-as-a-service (IaaS) cloud running on commonly available physical hardware.
The Red Hat OpenStack Platform (RHOSP) director Operator adds the ability to install and run a RHOSP cloud within OpenShift Container Platform (OCP).
Security Fixes:
* golang crypto/x509: Denial of Service via excessive processing of DNS SAN entries (CVE-2026-27145)
* Go crypto/tls: Denial of Service via multiple TLS 1.3 key update messages (CVE-2026-32283)
* Go net package: Denial of Service via long CNAME response in LookupCNAME (CVE-2026-33811)
* Go encoding/asn1: Denial of Service via excessive recursion in Unmarshal (CVE-2026-33818)
* golang.org/x/crypto/ssh: Denial of Service via crafted public key with excessive parameters (CVE-2026-39829)
* golang.org/x/crypto/ssh: Denial of Service via resource leak from unsolicited SSH responses (CVE-2026-39830)
* Golang MIME: Denial of Service via maliciously-crafted MIME header (CVE-2026-42504)
* golang.org/x/crypto/ssh: Denial of Service via crafted AES-GCM packet decoder inputs (CVE-2026-46597)
* Go net/http: Unencrypted HTTP/2 connections vulnerable to Denial of Service (CVE-2026-56853)
* Go html/template: Cross-Site Scripting via pathological input (CVE-2026-56858)
* Go: Denial of Service via XML decoding recursion depth issue (CVE-2026-56859)
* golang net/url: Denial of Service from quadratic complexity in path resolution (CVE-2026-56860)
* Golang crypto/tls: Denial of Service via indefinite KeyUpdate messages (CVE-2026-56862)
Enhancements:
* This release of OSPdO includes support for installation on OpenShift 4.20 platform (RHOSSTRAT-1291)
Bug Fixes:
* osp-director-operator no longer depends on the deprecated kube-rbac-proxy image (OSPRH-25893)
Payment Plugins for Stripe WooCommerce versions up to and including 4.0.17 are vulnerable to a reflected cross-site scripting (XSS) flaw via the '#response' URL fragment. This vulnerability arises from insufficient input sanitization and output escaping, allowing unauthenticated attackers to inject arbitrary scripts that execute when a user visits the crafted page. Exploitation depends on the 'Generic Errors' setting being unchecked, which causes raw Stripe error messages to be returned without sanitization.
A stored cross-site scripting (XSS) vulnerability exists in the GiveWP – Donation Plugin and Fundraising Platform for WordPress, affecting versions up to and including 4.17.0. The flaw arises from insufficient sanitization and escaping of user-supplied shortcode attributes, allowing authenticated users with Contributor-level access or higher to inject malicious scripts. These scripts execute whenever a user views the affected page, potentially compromising user interactions.
The Post Export Import with Media plugin for WordPress contains a directory traversal vulnerability in all versions up to and including 1.17.1. Authenticated users with administrator-level privileges can exploit this flaw by uploading a crafted ZIP archive containing a media_metadata.json file with path traversal sequences in the 'file_path' parameter. This allows reading arbitrary files on the server, potentially exposing sensitive information. The vulnerability bypasses extension checks introduced in version 1.13.2. The CVSS score is 4.9, indicating medium severity.
Improper authorization in the query resolvers generated by @aws-amplify/graphql-index-transformer in AWS Amplify API Category before 3.1.2 might allow an authenticated remote user to read records owned by other users of the same application via crafted queries.
This issue has been addressed in @aws-amplify/graphql-index-transformer 3.1.2 https://www.npmjs.com/package/@aws-amplify/graphql-index-transformer/v/3.1.2 (included in @aws-amplify/data-construct 1.17.4 https://www.npmjs.com/package/@aws-amplify/data-construct/v/1.17.4 and @aws-amplify/graphql-api-construct 1.21.4 https://www.npmjs.com/package/@aws-amplify/graphql-api-construct/v/1.21.4 ). We recommend upgrading to the latest version ensuring any forked or derivative code is patched to incorporate the new fixes and then redeploying their backend.
## Summary
Incomplete fix of GHSA-5v7c-xpfp-p65m: the secure-session (OTP step-up) requirement added to the nginx, cert, dns, backup, site, and stream mutation routers was not applied to the parallel api/cluster router, so cluster node management and cluster-wide nginx reload/restart run with only a JWT and no step-up. An authenticated user whose JWT is stolen or persisted, but who does not hold a fresh secure-session, can perform cluster node CRUD (including reading and rewriting a node token secret) and trigger cluster-wide nginx reload/restart. Confirmed at HEAD 2cb7ee9102c9d87274de2fa104db804841d140a0.
## The defect
GHSA-5v7c-xpfp-p65m required a fresh secure session (an OTP step-up beyond the JWT) for sensitive mutation routes. The fix wrapped the nginx, cert, dns, backup, site, and stream mutation handlers in middleware.RequireSecureSession() and added reload/restart to the MCP sensitive-tool list. It did not touch the physically separate api/cluster package, whose router registers the same class of sensitive operations on the bare authenticated group.
The fixed sibling, api/nginx/router.go:
```go
o := r.Group("", middleware.RequireSecureSession()) // line 28
{
o.POST("nginx/reload", Reload) // line 30
o.POST("nginx/restart", Restart) // line 31
}
```
The missed router, api/cluster/router.go, registers every sensitive operation directly on r with no RequireSecureSession wrapper:
```go
nodeGroup := r.Group("nodes") // line 9, no step-up
{
nodeGroup.POST("", AddNode) // line 12
nodeGroup.POST("/:id", EditNode) // line 13
nodeGroup.DELETE("/:id", DeleteNode) // line 14
}
r.POST("nodes/reload_nginx", ReloadNginx) // line 17
r.POST("nodes/restart_nginx", RestartNginx) // line 18
r.POST("namespaces", AddNamespace) // line 22
r.POST("namespaces/:id", ModifyNamespace) // line 23
r.DELETE("namespaces/:id", DeleteNamespace) // line 24
```
Both routers mount on the same group in router/routers.go: `g := root.Group("/", middleware.AuthRequired(), middleware.Proxy())` (line 87); nginx.InitRouter(g) creates its own RequireSecureSession subgroup, cluster.InitRouter(g) does not. So the cluster routes inherit only AuthRequired and Proxy, exactly the pre-fix posture the advisory closed for the nginx routes. AuthRequired has no role gate, so any authenticated user reaches them.
## Attacker model and impact
An authenticated, OTP-enabled user who does not present a fresh X-Secure-Session-ID (the parent advisory's model: a stolen or persisted JWT used without the step-up). Such a user can: add/edit/delete cluster nodes (AddNode/EditNode store an AES-serialized node token, the secret used to control a remote node, so this reads back and rewrites a cross-node credential); trigger nodes/reload_nginx and nodes/restart_nginx across the cluster (the exact reload/restart action class the fix protected on the single-node path); and add/modify/delete/reorder namespaces.
Proof of concept: with a valid JWT but no fresh secure session, call POST /api/nodes (AddNode) or POST /api/nodes/reload_nginx. The nginx equivalent POST /api/nginx/reload returns the secure-session challenge; the cluster route succeeds.
## Verification
Source-verified at HEAD: the nginx router wraps reload/restart in RequireSecureSession, the cluster router registers node/namespace/reload/restart directly on the group with no such wrapper, and both mount on the AuthRequired+Proxy-only group. I did not stand up a live nginx-ui.
## Suggested fix
Wrap the cluster router's mutation handlers (node CRUD, nodes/reload_nginx, nodes/restart_nginx, namespace CRUD) in middleware.RequireSecureSession(), mirroring api/nginx/router.go. Secondary lower-confidence items worth checking in the same pass: the system/restart handler, the core-upgrade websocket, and the upstream socket PUT also appear to run without the step-up (I did not fully trace these).
## Summary
nginx-ui supports two second-factor methods — TOTP (OTP) and WebAuthn passkeys —
and reports an account as 2FA-enabled when **either** is configured. However, the
password login endpoint (`POST /api/login`) only enforces a second factor when a
**TOTP secret** is present. An account that has registered a **passkey but no
TOTP** is logged in after password verification alone — the passkey is never
requested. This silently downgrades a passkey-protected account to single-factor
(password-only) authentication.
## Details
The account's 2FA policy treats passkeys as a valid factor (`model/user.go`):
```go
func (u *User) EnabledOTP() bool { return len(u.OTPSecret) != 0 }
func (u *User) EnabledPasskey() bool { /* true if a passkey row exists */ }
func (u *User) Enabled2FA() bool { return u.EnabledOTP() || u.EnabledPasskey() }
func (u *User) AfterFind(_ *gorm.DB) error {
u.EnabledTwoFA = u.Enabled2FA() // exposed to the UI as `enabled_2fa`
return nil
}
```
But the login handler only checks `EnabledOTP()` (`api/user/auth.go`, `Login`):
```go
u, err := user.Login(json.Name, json.Password)
...
if u.EnabledOTP() { // <-- only TOTP is enforced
if json.OTP == "" && json.RecoveryCode == "" {
c.JSON(http.StatusOK, LoginResponse{Message: "The user has enabled 2FA", Code: Enabled2FA}) // 199
user.BanIP(clientIP)
return
}
if _, err = user.VerifyOTP(u, json.OTP, json.RecoveryCode); err != nil { /* ... */ }
secureSessionID = user.SetSecureSessionID(u.ID)
}
// Passkey-only accounts fall through to here and receive a full session token:
accessToken, err := user.GenerateJWT(u)
```
No branch requires a WebAuthn assertion during password login when
`EnabledPasskey()` is true. The root cause is the mismatch between the
**policy definition** (`Enabled2FA()` = OTP **or** passkey) and the
**enforcement check** (`EnabledOTP()` only).
The same `EnabledOTP()`-only gating in `RequireSecureSession()`
(`internal/middleware/secure_session.go`) means passkey-only users are also
exempted from step-up on sensitive actions.
## Proof of Concept
Tested against nginx-ui built from source (`go build -tags unembed`) on
`127.0.0.1:9000`, with WebAuthn configured and a victim account that has a
registered passkey and **no** TOTP. The vulnerable code is identical on the
production `main` branch (`api/user/auth.go` `Login` gates on `u.EnabledOTP()`
only; verified at commit `6c86e5a`, 2026-05-17).
Account state advertised by `GET /api/2fa_status`:
```json
{"enabled":true,"otp_status":false,"passkey_status":true, ...}
```
Attacker logs in with **password only** (`POST /api/login`, encrypted params as
the client normally sends):
```
HTTP 200
{"message":"ok","code":200,"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...."}
```
`code: 200` + a valid JWT = an authenticated session, with the passkey never
used. For comparison, the identical account with a TOTP secret instead correctly
returns the second-factor challenge:
```
HTTP 200
{"message":"The user has enabled 2FA","code":199}
```
| Account state | `POST /api/login` (password only) |
|---|---|
| Passkey registered, no TOTP | `code 200` + JWT — **2FA NOT enforced** |
| TOTP registered | `code 199` — 2FA challenge enforced |
This isolates the defect: the login path enforces OTP but ignores passkeys.
## Impact
- Any account protected **only** by a passkey is reduced to password-only
authentication. An attacker who obtains the password (phishing, reuse, leak)
gains full access despite the registered security key.
- In nginx-ui all authenticated users are effectively administrators and the
terminal feature grants a host shell, so account takeover leads to full
control of the managed nginx instance / host.
- Users are given a false sense of security: the UI shows the account as
2FA-enabled while the second factor is not enforced at login.
## Remediation
- Gate the second-factor decision on `u.Enabled2FA()` (not `u.EnabledOTP()`) in
`Login`, in both SSO callbacks, and in `RequireSecureSession()`.
- For a passkey-only user logging in with a password, return a
"passkey assertion required" challenge and complete login only after a
successful WebAuthn assertion (the `begin_passkey_login` / `finish_passkey_login`
flow already exists and should be required as the second step).
- Centralize session-token issuance so no login entry point can skip the 2FA
decision.
## Affected components
- `api/user/auth.go` — `Login`
- `model/user.go` — `EnabledOTP`, `EnabledPasskey`, `Enabled2FA`, `AfterFind`
- `api/user/2fa.go` — `get2FAStatus`
- `internal/middleware/secure_session.go` — `RequireSecureSession`
CVE-2026-95597 is a Missing Authorization vulnerability in the 워드프레스 결제 심플페이 plugin for WooCommerce. It affects versions from 0 up to 5.5.17 and allows exploitation due to incorrectly configured access control security levels. The vulnerability can lead to integrity and availability impacts without requiring user interaction or privileges.
The Ultimate Multisite WordPress plugin before 2.17.0 does not require authentication before a logged-out checkout is linked to, and logged in as, an existing WordPress account matching the submitted email address, and its duplicate-account check normalizes that address differently from the lookup used to create the customer, so an unauthenticated attacker can log in as any existing user, including a Network Super Admin, whose email address they know.
This bypass is not addressed by the 2.15.1 fix for CVE-2026-75957 and remains exploitable in all versions up to and including 2.16.1, the releases that fix was expected to cover. Exploitation requires a checkout form configured without a password field (auto-generated password) and a target account that has no existing customer record in the Ultimate Multisite WordPress plugin before 2.17.0.