Where
-Infinity
0
Severity
8.7
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Description

When using the sandbox with a SourcePolicyInterface, Twig does not always apply the sandbox restriction that forbids non-Closure callbacks for callback-accepting filters.

The issue affects the sort, filter, map, and reduce filters.

In the affected versions, the runtime check that rejects non-Closure callbacks in sandbox mode does not use the current template Source. As a result, when the sandbox is enabled through a source policy instead of being enabled globally, Twig can incorrectly treat the current execution as non-sandboxed for these callback checks.

This can allow user-controlled templates to pass arbitrary PHP callables to callback-accepting filters even though the template is being sandboxed through a source policy.

The issue happens when all these conditions are met:

- The sandbox is not enabled globally; - A SourcePolicyInterface enables the sandbox for the rendered template; - The template uses one of the sort, filter, map, or reduce filters; - The callback is not a Closure.

Resolution

The patch makes callback sandbox checks source-aware by propagating the current template Source to callback-accepting filters and using it when deciding whether sandbox restrictions apply.

Credits

We would like to thank XavLim and Wade Sparks for reporting the issue and Fabien Potencier for fixing the issue.

1 / 4
Source: GitHub
First published (updated )
Severity
9.1
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

rsync 3.1.0 < 3.5.0 Access Control Bypass via DNS Resolution Failure

1 / 2
Source: Microsoft
First published (updated )
Severity
8.7
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

rsync before 3.5.0 contains an algorithmic complexity vulnerability in the hashsearch() function that allows a remote attacker to cause a denial of service by delivering a carefully constructed file list. A sender can exploit the quadratic-time worst-case behavior in hash lookups to exhaust receiver CPU resources with a modest number of crafted entries, causing a sustained denial of service.

1 / 2
Source: Red Hat
First published (updated )
Severity
8.8
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H

rsync 3.0.0 < 3.5.0 Out-of-Bounds Write via FLAGHLINKED Handling

1 / 2
Source: Microsoft
First published (updated )
Severity
9.2
Path Traversal
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

rsync 2.3.3 < 3.5.0 Path Traversal via --partial-dir/--backup-dir Symlink

1 / 3
Source: Microsoft
First published (updated )
Severity
8.8
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H

rsync 3.0.1 < 3.5.0 Heap Out-of-Bounds Write via readargs()

1 / 3
Source: Microsoft
First published (updated )
Severity
9.1
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

rsync before 3.5.0 contains a path confinement bypass vulnerability that allows remote clients to escape the intended inner-module root confinement by constructing paths that resolve outside the chroot boundary when the module root contains a /./ boundary marker. Attackers can exploit improper handling of the /./ notation or forge delta-basis transfers referencing xname paths that cross the /./ boundary to gain unauthorized read or write access to files outside the module's subtree.

1 / 2
Source: Red Hat
First published (updated )
Severity
8.6
Race Condition
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

rsync before 3.5.0 contains a time-of-check to time-of-use (TOCTOU) race condition vulnerability in the rrsync restricted shell wrapper that allows authenticated clients to escape enforced directory restrictions by substituting a symlink for a path component after validation but before transfer processing. Attackers can additionally leverage unrestricted flags such as --copy-unsafe-links, -D, and --log-file through rrsync to read or write files outside the permitted directory subtree.

1 / 2
Source: Red Hat
First published (updated )
Severity
9.2
OS Command Injection
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

rsync before 3.5.0 contains multiple command and argument injection vulnerabilities that allow attackers to execute arbitrary commands by supplying malicious input through several code paths, including the RSYNCCONNECTPROG environment variable, daemon hooks, the rsync-ssl wrapper, and remote-shell command newline injection. Attackers can inject shell metacharacters or newline characters into unsanitized user-supplied values such as hostnames and hostspecs to execute arbitrary commands under the privileges of the rsync process or the invoking user.

1 / 2
Source: Red Hat
First published (updated )
Severity
6.9
Path Traversal
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

rsync before 3.5.0 contains a path traversal vulnerability that allows a malicious sender to write files outside the intended destination directory tree by crafting relative paths with symlink components in --relative mode. The makepath() function follows symlinks pointing outside the destination tree while creating intermediate directories without verifying that created paths remain within the destination boundary, enabling arbitrary file writes on the receiver's filesystem.

1 / 2
Source: Red Hat
First published (updated )
Severity
3.7
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

A flaw was found in OpenSSH. This vulnerability, a heap out-of-bounds read, occurs during the cleanup of GSSAPI (Generic Security Service Application Programming Interface) indicators when a trailing NULL termination is missing in the auth-indicators array. A remote attacker, under specific configurations involving GSSAPI authentication and a Kerberos environment, could exploit this to cause the SSH authentication path to crash or abort. This leads to a denial of service (DoS), impacting the availability of the SSH service.

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow low-privileged users to query arbitrary indices and read sensitive data due to missing authorization.

1 / 2
Source: MITRE
First published (updated )
Severity
7.5
SSRF
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow an authenticated attacker to send unauthorized requests from the system due to server-side request forgery. This could be used to enumerate network resources or to support further attacks.

1 / 2
Source: MITRE
First published (updated )
Severity
9.6
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:H

BM API Connect Analytics (analytics-v2-director) versions in the v10.0.8 release stream are vulnerable to a Regular Expression Denial of Service (ReDoS) attack and to improper neutralisation of wildcard query operators.

1 / 2
Source: IBM
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote attacker to read arbitrary files on the server due to external control of a file name or path.

1 / 2
Source: MITRE
First published (updated )
Severity
7.7
SSRF
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery.

1 / 2
Source: MITRE
First published (updated )
Severity
5
SSRF
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to probe internal network services due to improper validation of a user-supplied URL.

1 / 2
Source: MITRE
First published (updated )
Severity
6.5
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote attacker to obtain sensitive information due to the use of a hard-coded cryptographic key.

1 / 2
Source: MITRE
First published (updated )
Severity
5
SSRF
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery.

1 / 2
Source: MITRE
First published (updated )
Severity
8.2
XEE
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote attacker to obtain sensitive information due to XML external entity (XXE) injection.

1 / 2
Source: MITRE
First published (updated )
Severity
7.7
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to an insecure direct object reference.

1 / 2
Source: MITRE
First published (updated )
Severity
5.3
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote attacker to enumerate usernames due to observable differences in response behavior.

1 / 2
Source: MITRE
First published (updated )
Severity
6.8
AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to the insertion of sensitive information into log files.

1 / 2
Source: MITRE
First published (updated )
Severity
4
AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a local attacker to obtain sensitive information due to improper use of cryptography. The encryption applied to stored data is not implemented with sufficient strength, which weakens its protection.

1 / 2
Source: MITRE
First published (updated )
Severity
7.7
SQL Injection
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information belonging to other tenants due to an injection vulnerability. Input used to build a data query is not properly neutralized, which could allow the query to return data the user is not permitted to see.

1 / 2
Source: MITRE
First published (updated )
Severity
7.7
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to broken object-level authorization.

1 / 2
Source: MITRE
First published (updated )
Severity
5.8
SSRF
AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to a server-side request forgery vulnerability.

1 / 2
Source: MITRE
First published (updated )
Severity
5.8
Command Injection, CRLF Injection, CSRF
AV:L/AC:L/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Summary Several Net::IMAP commands accept a raw string argument that is sent to the server without validation or escaping. If this string is derived from user-controlled input, it may contain contain CRLF sequences, which an attacker can use to inject arbitrary IMAP commands.

Details

Net::IMAP's generic argument handling, used by most command arguments, interprets string arguments as an IMAP astring. Depending on the string contents and the connection's UTF-8 support, this encodes strings as either a atom, quoted, or literal. These are safe from command or argument injection.

But the following commands transform specific String arguments to Net::IMAP::RawData, which bypasses normal argument validation and encoding and prints the string directly to the socket: #uidsearch, #search when criteria is a String, it is sent raw #uidfetch, #fetch when attr is a String, it is sent raw when attr is an Array, each String in attr is sent raw #uidstore, #store when attr is a String, it is sent raw #setquota: limit is interpolated with #tos and that string is sent raw

Because these string arguments are sent without any neutralization, they serve as a direct vector for command splitting. Any user controlled data interpolated into these strings can be used to break out of the intended command context.

Using "raw data" arguments for #uidstore, #store, and #setquota I both inappropriate and unnecessary. Net::IMAP's generic argument handling is sufficient to safely validate and encode their arguments. Users of the library probably do not expect arguments to these commands to be sent raw and might not be wary of passing unvalidated input.

The API for search criteria and fetch attributes is intentionally low-level and "close to the wire". It allows developers to use some IMAP extensions without requiring explicit support from the library and allows developers to use complex IMAP grammar without complex argument translation. Even so, basic validation is appropriate and could neutralize command injection.

Although this was explicitly documented for search criteria, it was insufficiently documented for fetch attr. So developers may not have realized that the attr argument to #fetch and #uidfetch is sent as "raw data".

Impact

If a developer passes an unvalidated user-controlled input for one of these method arguments, an attacker can append CRLF sequence followed by a new IMAP command (like DELETE mailbox). Although this does not directly enable data exfiltration, it could be combined with other attack vectors or knowledge of the target system's attributes, e.g.: shared mail folders or the application's installed response handlers.

The SEARCH, STORE, and FETCH commands, and their UID variants are some of the most commonly used features of the library. Applications that build search queries or fetch attributes dynamically based on user input (e.g., mail clients or archival tools) may be at significant risk.

Expected use of Net::IMAP#setquota is much more limited: SETQUOTA is often only usable by users with special administrative privileges. Depending on the server, quota administration might be managed through server configuration rather than via the IMAP protocol SETQUOTA command. It is expected to be uncommonly used in system administration scripts or in interactive sessions, it should be completely controlled by trusted users, and should only use trusted inputs. Calling #setquota with untrusted user input is expected to be a very uncommon use case. Please note however this might be combined with other attacks, for example CSRF, which provide unauthorized access to trusted inputs, and may specifically target users or scripts with administrator privileges.

Mitigation - Update to a patched version of net-imap which: - validates that Net::IMAP::RawData is composed of well-formed IMAP text, literal, and literal8 values, with no unescaped NULL, CR, or LF bytes. - does not use Net::IMAP::RawData for #store, #uidstore, or #setquota. - Prefer to send search criteria as an array of key value pairs. Avoid sending it as an interpolated string. - If an immediate upgrade is not possible: - String inputs to search criteria and fetch attributes can be validated against command injection by checking for \r and \n characters. - Hard-coding the store attr argument is often appropriate. Alternatively, user controlled inputs can be restricted to a small enumerated list which is valid for the calling application. - Use Kernel#Integer to coerce and validate user controlled inputs to #setquota limit.

1 / 3
Source: GitHub
First published (updated )
Severity
6.3
XSS
AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Prior to 3.4.7, DOMPurify INPLACE sanitization could skip shadow contents attached to an element inside <template>.content, allowing attacker-controlled markup such as event handlers, JavaScript URLs, or scripts to survive and execute when an application cloned and inserted the sanitized template. This issue is fixed in version 3.4.7.

1 / 3
Source: MITRE
First published (updated )
Severity
5.3
XEE
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Insecure XML parser configuration in Apache CXF's WS-Transfer module may allow attackers to perform XXE attacks. Users are recommended to upgrade to versions 4.2.1, 4.1.6 or 3.6.11, which fix this issue.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203