CVE-2026-78358 is a Cross-Site Request Forgery (CSRF) vulnerability in OTRS versions 6.x through 8.x and 2023.x through 2026.6.x. It allows unauthenticated remote attackers to cause an authenticated administrator's browser to perform unintended administrative actions, such as deleting DBUpdate log entries, by embedding crafted requests in malicious web pages. The vulnerability affects several administrative and export endpoints that do not validate ChallengeTokens, but no direct confidentiality impact has been demonstrated. The impact is limited to the deletion of existing DBUpdate log entries, potentially reducing availability of diagnostic and audit information.
CVE-2026-48211 is a Cross-Site Request Forgery (CSRF) vulnerability in OTRS software versions 6.0.0 through 2026.6.x. It allows an unauthenticated remote attacker to trick an authenticated administrator into deleting administrative Import/Export templates by exploiting the lack of ChallengeToken validation in the AdminImportExport::TemplateDelete action.
The Hotel Booking WordPress plugin through 3.8 does not implement CSRF protection on its administrative booking order management, allowing attackers to trick a logged-in administrator into creating, deleting, or modifying arbitrary booking order records via a forged request.
The SmugMug Embed WordPress plugin through 3.13 does not have authorisation or CSRF checks on an AJAX action that stores gallery data, and does not sanitise or escape that data before outputting it, allowing unauthenticated users to store arbitrary web scripts that execute when an administrator views the SmugMug Embed WordPress plugin through 3.13's settings screen.
The click5 CRM add-on to Contact Form 7 WordPress plugin through 1.0.4 does not have authorisation and CSRF checks when updating options via a REST endpoint, and does not ensure that the option to be updated belongs to the click5 CRM add-on to Contact Form 7 WordPress plugin through 1.0.4. As a result, unauthenticated attackers could change arbitrary blog options, allowing them to create a new administrator account and take over the site.
The click5 CRM add-on to Gravity Forms WordPress plugin through 1.0.3 does not have authorisation and CSRF checks when updating options via a REST endpoint, and does not ensure that the option to be updated belongs to the click5 CRM add-on to Gravity Forms WordPress plugin through 1.0.3. As a result, unauthenticated attackers could change arbitrary blog options, allowing them to create a new administrator account and take over the site.
The click5 CRM add-on to WPForms WordPress plugin through 1.0.3 does not have authorisation and CSRF checks when updating options via a REST endpoint, and does not ensure that the option to be updated belongs to the click5 CRM add-on to WPForms WordPress plugin through 1.0.3. As a result, unauthenticated attackers could change arbitrary blog options, allowing them to create a new administrator account and take over the site.
The click5 CRM add-on to Ninja Forms WordPress plugin through 1.0.1 does not have authorisation and CSRF checks when updating options via a REST endpoint, and does not ensure that the option to be updated belongs to the click5 CRM add-on to Ninja Forms WordPress plugin through 1.0.1. As a result, unauthenticated attackers could change arbitrary blog options, allowing them to create a new administrator account and take over the site.
The Prenotazioni WordPress plugin through 1.7.5 does not have authorisation and CSRF checks when saving its settings, and does not escape some of them when outputting them, allowing unauthenticated users to perform Stored Cross-Site Scripting attacks against administrators and site visitors.
## Summary
Nginx-UI v2.4.3 stores the API JWT in a browser cookie named `token` and the `AuthRequired` middleware accepts that cookie as an authentication source. Because management endpoints are protected by `AuthRequired` and do not enforce a universal CSRF token or Origin/Referer check, a remote attacker can induce a logged-in administrator to submit cross-site state-changing requests. The attacker does not need to read the cross-origin response; the browser-sent cookie is enough to authenticate the request.
## Details
The root cause is a trust-boundary failure between browser-managed cookies and API bearer-token authentication. In `app/src/pinia/moudule/user.ts:25-35`, the front end writes the JWT to a `token` cookie when the token changes. In `internal/middleware/middleware.go:16-36`, `getToken` first checks the `Authorization` header and `token` query parameter, then falls back to `c.Cookie("token")`. That fallback causes browser-initiated cross-site requests to carry a valid API credential automatically. The route group in `router/routers.go:87-110` applies `middleware.AuthRequired()` to many management modules, including `config.InitRouter`, `nginx.InitRouter`, `settings.InitRouter`, and backup-related handlers. For accounts without OTP/Passkey, `RequireSecureSession` does not provide a universal second factor for all state-changing operations. A representative sink is `api/config/add.go:68-78`, where an authenticated request writes Nginx configuration with `os.WriteFile` and then calls `nginx.Control(nginx.Reload)`. CORS does not mitigate this issue because preventing cross-origin response reads does not prevent cross-site form or no-cors requests from being sent with cookies.
Core vulnerable code path:
```typescript
// app/src/pinia/moudule/user.ts:25-35
watch(token, v => {
if (v) {
cookies.set('token', v, getCookieOptions(86400))
if (!shortToken.value) {
void fetchShortToken()
}
}
else {
cookies.remove('token', { path: '/' })
shortToken.value = ''
}
})
```
The front end stores the authentication token in a `token` cookie. The cookie is created client-side and is not shown here as HttpOnly; it becomes the credential that the back end later accepts through cookie fallback.
```go
// internal/middleware/middleware.go:16-36
// getToken from header, cookie or query
func getToken(c *gin.Context) (token string) {
if token = c.GetHeader("Authorization"); token != "" {
return
}
if token = c.Query("token"); token != "" {
if len(token) > 16 {
// Long token (base64 encoded JWT)
tokenBytes, _ := base64.StdEncoding.DecodeString(token)
return string(tokenBytes)
}
// Short token (16 characters)
return token
}
if token, _ = c.Cookie("token"); token != "" {
return token
}
return ""
}
```
`getToken` accepts the `token` cookie as an authentication credential after checking the header and query parameter. That behavior lets a browser-sent cookie authenticate state-changing API requests triggered from another origin.
```go
// router/routers.go:87-110
// Authorization required and not websocket request
g := root.Group("/", middleware.AuthRequired(), middleware.Proxy())
{
debug.InitRouter(g)
user.InitUserRouter(g)
analytic.InitRouter(g)
user.InitManageUserRouter(g)
nginx.InitRouter(g)
sites.InitRouter(g)
streams.InitRouter(g)
config.InitRouter(g)
template.InitRouter(g)
certificate.InitCertificateRouter(g)
certificate.InitDNSCredentialRouter(g)
certificate.InitAcmeUserRouter(g)
dnsapi.InitRouter(g)
system.InitPrivateRouter(g)
settings.InitRouter(g)
llm.InitRouter(g)
cluster.InitRouter(g)
notification.InitRouter(g)
external_notify.InitRouter(g)
backup.InitAutoBackupRouter(g)
nginxLog.InitRouter(g)
upstream.InitHTTPRouter(g)
```
Many management modules, including Nginx, configuration, settings, backup, and user management, are placed behind `AuthRequired`. The cookie fallback therefore protects high-impact state-changing routes, not only read-only endpoints.
```go
// api/config/add.go:68-78
err = os.WriteFile(path, []byte(content), 0644)
if err != nil {
cosy.ErrHandler(c, err)
return
}
res := nginx.Control(nginx.Reload)
if res.IsError() {
res.RespError(c)
return
}
```
This representative sink shows why the CSRF is high impact: once authenticated through the cookie fallback, a request can write Nginx configuration content and trigger a reload.
## POC
Prerequisites: an administrator is logged in to Nginx-UI and has a browser `token` cookie; the administrator account has not enabled OTP/Passkey, or the chosen target endpoint does not require secure-session proof; the attacker knows the Nginx-UI management URL and can induce the administrator to visit an attacker-controlled page. Reproduction: (1) Host an attacker page at `GET /csrf.html` that automatically submits a cross-site request to the victim instance. (2) The page submits `POST /api/configs`
The GDPR Data Request Form WordPress plugin through 1.7.1 does not have CSRF protection when updating one of its settings, allowing attackers to change that setting via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.
IBM Security Verify Access versions 10.0 through 10.0.9.2 and IBM Verify Identity Access versions 11.0 through 11.0.3 are affected by a cross-site request forgery (CSRF) vulnerability. This flaw could allow an attacker to trick a user into executing unauthorized actions on a trusted website. The vulnerability has a medium severity rating with a CVSS score of 4.3. No known exploits are reported in the wild, and no official patch information is provided in the available data.
CVE-2026-107337 is a high-severity Cross-Site Request Forgery (CSRF) vulnerability in the Malcolm kiosk Flask application by CISA. The application exposes a POST endpoint /script_call/<script> without any authentication and uses wildcard CORS, allowing attackers to trick an operator's browser into executing arbitrary management commands. Exploitation can lead to destructive actions such as permanently deleting all captured network traffic and forensic logs or stopping security monitoring. This vulnerability affects Malcolm versions from 0 up to and including 26.07.1.
### Summary
The Pydantic AI development web chat UI (`Agent.to_web()`, `clai web`) did not check the content type of requests to its chat endpoint. This allowed a website visited by a developer to submit a request to a chat UI running on that developer's machine, causing the served agent to run and to execute its tools with the privileges and credentials of the local process.
Binding the web UI to localhost — the default — does not prevent this, because a page open in the developer's browser can reach the loopback address.
### Impact
Applications and developers serving an agent through `Agent.to_web()` or `clai web`. The consequences depend on the tools the served agent exposes, and can include data disclosure as well as unwanted tool side effects. Tools marked `requires_approval=True` were not protected either, because the endpoint trusts approval decisions relayed by the client.
### Mitigation
Upgrade to a patched version. The chat endpoint now requires `Content-Type: application/json` and rejects other requests before the request body is parsed and before the agent runs. The bundled chat UI already sends this header; scripts and other non-browser clients that call the endpoint directly may need to be updated to send it.
If you cannot upgrade, don't run the web UI while browsing untrusted sites, stop it when you aren't using it, and don't serve an agent with side-effecting tools through it.
### Credits
- Thai Son Dinh from VinSOC Labs (R&D)
A Cross-Site Request Forgery (CSRF) vulnerability exists in the balbooa.com Gridbox extension for Joomla versions 1.0.0 through 2.20.3.1. The vulnerability arises because the addLanguage action does not require a POST request and thus bypasses the Joomla session token validation that is only enforced on POST methods. This allows a GET request to trigger the action without verifying the token, potentially enabling unauthorized actions if the victim has the required permissions.
The Database Addon For WPForms ( wpforms entries ) WordPress plugin before 1.1.1 does not verify the CSRF nonce when the field is omitted and performs no capability check of its own, allowing attackers to delete arbitrary stored form entries by tricking a logged-in administrator into loading a crafted page.
wger is a free, open-source workout and fitness manager. Prior to version 2.6, the `trainer_login` view in wger accepts GET requests and executes `django_login()` without any CSRF protection, because Django's `CsrfViewMiddleware` only enforces tokens on unsafe methods (POST/PUT/PATCH/DELETE). An attacker can embed a single `<img>` tag on a malicious page; when an authenticated trainer loads that page, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer's session to an arbitrary user account. Version 2.6 fixes the issue.
Joplin is an open source note-taking and to-do application that organises notes and lists into notebooks. Prior to 3.7.13, when Joplin Desktop is running with the opt-in Web Clipper server enabled, the server in packages/lib/ClipperServer.ts sends Access-Control-Allow-Origin: * and allows an arbitrary website to call POST /auth and GET /auth/check because the pairing endpoints do not reject HTTP or HTTPS origins. The desktop confirmation dialog does not identify the requesting origin, so a victim who approves the generic prompt authorizes the attacking page, which then receives the permanent API token. The token provides ongoing read and write access to notes, folders, tags, resources, and master keys. This issue is fixed in version 3.7.13.
Joomla Extension - svenbluege.de - Cross-site scripting and open redirect on the share mini page in Event Gallery extension < 6.6.0 - The page a shared image link opens (the share mini page of the front end) can link the article the image was shared from when the option "Share article links" is on. It took the address of the article from the shared link and printed it into the page without checking or escaping it; with the link type "Image Page with Redirect" it followed the address at once. A prepared link could therefore run a script in the page, in the session of the visitor who opened it, or send the visitor to another web site. Nothing on the server is changed or read by the server.
A Cross-Site Request Forgery (CSRF) vulnerability exists in the Event Gallery extension for Joomla versions 1.0.0 through 6.5.0. This flaw allows an attacker to trick a logged-in administrator into performing certain backend list tasks without proper form token verification. The affected tasks include setting default payment and shipping methods, image type sets, order status, watermark settings, managing event shop status, selecting main event images, and sorting event images. The vulnerability does not allow deletion or reading of data, nor does it affect orders.