REDAXO core versions before 5.21.0 have a reflected cross-site scripting (XSS) vulnerability in the backend packages API. The flaw arises because a function parameter is concatenated into an error message without proper HTML escaping. An attacker can exploit this by tricking an authenticated backend user into clicking a crafted link containing a valid CSRF token, leading to JavaScript execution that can perform same-origin actions or read DOM data. This vulnerability is fixed in version 5.21.0.
REDAXO before 5.21.0 contains a reflected cross-site scripting vulnerability that allows authenticated attackers to inject scripts via the type parameter of the metainfo_default_fields_create API. Attackers can craft a link with a valid CSRF token and HTML payload that rex_view::message() renders unescaped, executing scripts in a victim's backend session.
REDAXO core versions before 5.21.3 have a cross-site request forgery (CSRF) vulnerability in the backend user administration page. The flaw exists because the CSRF token validation only occurs when the 'save' parameter is set, but not during the update path triggered by FUNC_UPDATE. This allows attackers to trick logged-in backend users with user management permissions into executing unauthorized actions such as granting administrator rights, deactivating accounts, or locking out the sole administrator via crafted GET requests.
REDAXO core versions before 5.21.3 have a reflected cross-site scripting (XSS) vulnerability in the backend media pool detail page. The vulnerability arises because the opener_link parameter is rendered without HTML escaping. An unauthenticated attacker can trick logged-in backend users with media permissions into clicking a crafted link, allowing script injection. This injected script can read the victim's CSRF token and perform actions with the victim's permissions, including code execution via template or module edits if the victim is an administrator. The issue is fixed in version 5.21.3.
REDAXO core versions before 5.21.3 have a cross-site request forgery (CSRF) vulnerability in the structure/history plugin. This flaw allows attackers to trick authenticated backend users into performing actions via crafted GET requests that can delete all article snapshots or revert articles to previous states. The vulnerability is fixed in version 5.21.3.
REDAXO from 5.18.0 before 5.21.4 contains a stored cross-site scripting vulnerability because rex_media_service moves uploaded SVG files into the public media folder before sanitizing them. Authenticated users with mediapool upload rights can race the sanitizer or exhaust memory limits to leave script-laden SVGs publicly served, executing scripts in victims' backend sessions.
REDAXO core versions from 5.3.0 up to but not including 5.21.4 contain an authentication bypass vulnerability in the structure/history plugin. This flaw allows unauthenticated attackers to forge temporary login tokens by forcing the session-tied secret into a predictable state. Successful exploitation enables attackers to gain backend access as privileged users such as admin and execute code outside of live mode. The vulnerability has a critical severity with a CVSS 4.0 score of 9.3. A fix is available in version 5.21.4.
REDAXO core versions before 5.21.4 have a stored cross-site scripting (XSS) vulnerability. This flaw allows content editors to inject malicious HTML via unescaped values in media, medialist, link, and linklist widgets. Attackers can craft input values that break out of HTML attributes, enabling script execution in administrator backend sessions and potentially hijacking accounts. The vulnerability is fixed in version 5.21.4.
REDAXO core versions before 5.21.4 have an authorization bypass vulnerability that allows authenticated editors to modify slices in categories they are not authorized to access. By pairing a permitted article with a foreign slice ID, attackers can delete, toggle, move, or overwrite slices belonging to other editors via content editing and slice management APIs.
REDAXO before 5.21.4 contains a missing authorization vulnerability in the media pool bulk move that checks only target category permission, ignoring the source category. Authenticated backend users with permission for one media category can move files from restricted categories into it, then silently replace their contents site-wide.
REDAXO core versions before 5.21.4 have a missing authorization vulnerability in the structure/version and structure/history frontend preview modes. These modes do not verify category or clang permissions for the previewed article, allowing any backend user or users with the history[article_rollback] permission to access unpublished, historic, or deleted content by manipulating parameters.
REDAXO core versions before 5.21.5 have a missing authorization vulnerability in the backup addon export functionality. This flaw allows non-admin users with the backup[export] permission to export sensitive database tables, including rex_user and rex_user_session. Exploiting this, attackers can obtain plaintext session IDs and stay-logged-in keys to hijack admin accounts or acquire password hashes for offline cracking.
REDAXO core versions before 5.21.5 have a cross-site request forgery (CSRF) vulnerability in the backend. The vulnerability arises because the safemode GET parameter in index.php is processed without validating a CSRF token. An attacker can exploit this by tricking a logged-in administrator into clicking a crafted link that disables global safe mode or enables session safe mode, affecting backend addon functionality.
REDAXO before 5.21.5 contains an insufficient session expiration vulnerability that allows attackers to retain account access by keeping the current session and stay-logged-in key valid after a password change. Attackers who obtained a user's session id or stay-logged-in cookie can keep backend access after the password change, via the cookie for up to three months.
REDAXO core versions before 5.21.5 have a missing authorization vulnerability in the rex_api_package API function. This flaw allows non-admin backend users who possess a valid CSRF token to manage packages, including uninstalling system addons, deactivating, installing, activating packages, and deleting non-system packages. The vulnerability is fixed in version 5.21.5.
Anthropic, an AI company, disclosed in its IPO filing with the SEC that its AI technologies pose significant risks including potential misuse by bad actors and the possibility of AI systems acting autonomously with harmful consequences. The filing highlights concerns about rapid AI development outpacing safety measures, risks of AI being weaponized or used for harmful surveillance, and operational challenges such as securing compute resources. Anthropic positions its IPO as a step toward mitigating these risks by emphasizing safety and responsible AI development.
CVE-2026-117466 is a privilege escalation vulnerability in Octopus Deploy's Octopus Server. Users with the System Manager role can escalate their privileges to full system Administrator. This affects specific versions prior to fixed releases in 2026.2.13469 and 2026.3.15863. The vulnerability has a high severity score of 8.6 and does not require user interaction for exploitation.
CVE-2026-117341 is a vulnerability in Octopus Deploy Octopus Server where creating a user invitation causes the invitation code to be logged in the audit event log. Users with appropriate permissions in the linked space can read this code and potentially redeem the invitation to escalate privileges. The impact depends on the permissions assigned to the invited user. This issue affects specific versions of Octopus Server and has been fixed in versions 2026.2.13438 and 2026.3.15829.
## Summary
The venv creator reads the standard library's generated pyvenv.cfg with splitlines() and merges all resulting keys over
virtualenv's configuration. Line-boundary characters from destination data can therefore become configuration structure
before output sanitization.
Anthropic's OSS Scanner reported this as `ANT-2026-6ZQHJ6VI` in `virtualenv-20261015-005`, received on 15 October 2026.
## Affected area
Configuration readback by the stdlib venv creator.
## Attacker-controlled input
An untrusted caller must influence the destination pathname passed to the venv creator. That pathname must contain a
character that Python treats as a line boundary. The builtin creator follows a different configuration-writing path.
## Affected code
The relevant 21.14.8 source is in
[venv readback](https://github.com/pypa/virtualenv/blob/a795ab116356afde11039cf2763d77e8a06da738/src/virtualenv/create/via_global_ref/venv.py),
[configuration parser](https://github.com/pypa/virtualenv/blob/a795ab116356afde11039cf2763d77e8a06da738/src/virtualenv/create/pyenv_cfg.py).
## Mechanism
With `--creator venv`, virtualenv asks the standard library to create an environment, reads its `pyvenv.cfg` with
`str.splitlines()`, and merges the parsed keys over virtualenv's chosen settings. CPython writes the destination into a
`command =` value without escaping every character that `splitlines()` recognizes as a line boundary. A destination
containing U+2028, for example, can therefore supply new `home` and `include-system-site-packages` keys during readback.
Virtualenv writes those keys as real configuration lines. The builtin creator does not use this readback path.
## Reproduction and evidence
The scanner used one destination value with U+2028 between `home = /attacker/chosen`,
`include-system-site-packages = true`, and an absorbing `x =` key. A `python -m venv --without-pip` control kept the
value inside its `command` line and reported the base interpreter's `sys._home`. `virtualenv --creator venv --no-seed`
on the same value wrote separate injected configuration lines and its interpreter reported
`sys._home = /attacker/chosen`. The path did not require a literal newline byte. The control establishes that the extra
keys came from virtualenv's readback, not from the standard library's initial file alone.
The altered `home` can change which standard-library files the interpreter loads if an attacker also controls that
location; `include-system-site-packages = true` weakens environment isolation. Choosing the venv creator is required,
either explicitly or through a rare fallback. The report traces the readback to the 20.x rewrite, first released in
20.0.0b1. [PR #3426](https://github.com/pypa/virtualenv/pull/3426) rejects line-boundary characters before creation and
rebuilds the final configuration from selected settings.
## Attack sequence
```mermaid
sequenceDiagram
participant A as Destination supplier
participant S as stdlib venv
participant V as virtualenv readback
participant C as Final pyvenv.cfg
participant P as Environment Python
A->>S: path contains U+2028 and home = /attacker/chosen
S->>C: write path inside command value
V->>C: read with splitlines()
V->>V: parse suffix as separate keys
V->>C: rewrite home and include-system-site-packages
P->>C: read injected keys on startup
C-->>P: sys._home changes and isolation is disabled
```
## Reproducer files
The following files are from the scanner report for `ANT-2026-6ZQHJ6VI`. They were tested against commit `a857a7823c73`
in the scanner image. The `repro` entrypoint expects companion files under `/tmp/repro.d`; cases that change user IDs
need a disposable root-capable container. The last output line is `BUG` when the reported behavior occurs. These files
are included as evidence and were not rerun for this advisory update.
**`repro`**
```text
#!/usr/bin/env python3
import os
import shutil
import subprocess
work = "/tmp/repro-venv-creator-cfg"
shutil.rmtree(work, ignore_errors=True)
# the attacker's input: the text of a destination path.
# U+2028 ends a line for str.splitlines() but not for CPython's own pyvenv.cfg reader.
# The slashes only make nested directories; the last key, x, absorbs the rest of the path.
LS = "\u2028"
dest = f"{work}/proj{LS}home = /attacker/chosen{LS}include-system-site-packages = true{LS}x = /env"
base_python = os.path.realpath(shutil.which("python"))
real_home = os.path.dirname(base_python)
def pyvenv_cfg_lines(env):
# split on "\n" only, as the interpreter does
return open(f"{env}/pyvenv.cfg", encoding="utf-8").read().split("\n")
def sys_home(env):
# site.py sets sys._home from the `home` key of the environment's pyvenv.cfg
probe = [f"{env}/bin/python", "-c", "import sys; print(sys._home)"]
return subprocess.run(probe, capture_output=True, text=True, check=True).stdout.strip()
# control: the same path through the standard library alone
stdlib_env = dest + "-stdlib"
CVE-2026-116870 is a high-severity vulnerability in Octopus Deploy Octopus Server where OIDC token issuer validation was inconsistently performed. This flaw could allow a token from a non-legitimate issuer to be accepted as if it belonged to a legitimate trusted service account. Exploitation requires a service account with an OIDC identity configured and some knowledge of that identity. Fixed versions are available.