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 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.

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.

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.

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

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 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 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 path traversal vulnerability exists in rsync. It stems from behavior enabled by the --inc-recursive option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the --inc-recursive option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client.

A flaw was found in rsync which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.

An issue was discovered in psi/zcolor.c in Artifex Ghostscript before 10.04.0. An unchecked Implementation pointer in Pattern color space could lead to arbitrary code execution.

An issue was discovered in base/gsdevice.c in Artifex Ghostscript before 10.04.0. An integer overflow when parsing the filename format string (for the output filename) results in path truncation, and possible path traversal and code execution.

An issue was discovered in psi/zfile.c in Artifex Ghostscript before 10.04.0. Out-of-bounds data access in filenameforall can lead to arbitrary code execution.

A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.

Impact

A vulnerability has been identified which may lead to sensitive data being leaked into Rancher's audit logs. Rancher Audit Logging is an opt-in feature, only deployments that have it enabled and have AUDITLEVEL set to 1 or above are impacted by this issue.

The leaks might be caught in the audit logs upon these actions:

- Creating cloud credentials or new authentication providers. It is crucial to note that all authentication providers (such as AzureAD) and cloud providers (such as Google) are impacted. - Downloading a kubeconfig file from a downstream or a local cluster. - Logging in/out from Rancher.

The affected data may include the following:

- HTTP headers

Field | Location -- | -- X-Api-Auth-Header | Request header X-Api-Set-Cookie-Header | Response header X-Amz-Security-Token | Request header credentials | Request body applicationSecret | Request Body oauthCredential | Request Body serviceAccountCredential | Request Body spKey | Request Body spCert | Request body spCert | Response body certificate | Request body privateKey | Request body - API Server calls returning Secret objects (including sub-types, such as kubernetes.io/dockerconfigjson). - Raw command lines used by agents to connect to the Rancher server which expose sensitive information (e.g. register ... --token abc). - Kubeconfig contents when the 'Download KubeConfig' feature is used in the Rancher UI.

The patched versions will redact the sensitive data, replacing it with [redacted], making it safer for consumption. It is recommended that static secrets are rotated after the system is patched, to limit the potential impact of sensitive data being misused due to this vulnerability.

Note: 1. The severity of the vulnerability is intricately tied to the logging strategy employed. If logs are kept locally (default configuration), the impact is contained within the system, limiting the exposure. However, when logs are shipped to an external endpoint, the vulnerability's severity might increase, as resistance against leaks is contingent on the security measures implemented at the external log collector level. 2. The final impact severity for confidentiality, integrity and availability is dependent on the permissions that the leaked credentials have on their own services.

Patches Patched versions include releases 2.6.14, 2.7.10 and 2.8.2.

Workarounds If AUDITLEVEL 1 or above is required and you cannot update to a patched Rancher version, ensure that the log is handled appropriately and it is not shared with other users or shipped into a log ingestion solution without the appropriate RBAC enforcement. Otherwise, disabling the Audit feature or decreasing it to the audit level 0, mitigates the issue.

For more information

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 Improper Link Resolution Before File Access ('Link Following') vulnerability in SUSE SUSE Linux Enterprise Desktop 15 SP5 postfix, SUSE SUSE Linux Enterprise High Performance Computing 15 SP5 postfix, SUSE openSUSE Leap 15.5 postfix.This issue affects SUSE Linux Enterprise Desktop 15 SP5: before 3.7.3-150500.3.5.1; SUSE Linux Enterprise High Performance Computing 15 SP5: before 3.7.3-150500.3.5.1; openSUSE Leap 15.5 : before 3.7.3-150500.3.5.1.

Impact

An issue was found in RKE2 where an attacker with network access to RKE2 servers' supervisor port (TCP 9345) can force the TLS server to add entries to the certificate's Subject Alternative Name (SAN) list, through a stuffing attack, until the certificate grows so large that it exceeds the maximum size allowed by TLS client implementations. OpenSSL for example will raise an excessive message size error when this occurs. No authentication is necessary to perform this attack, only the ability to perform a TLS handshake against the supervisor port (TCP 9345).

Affected servers will continue to operate, but clients (server or agent nodes) will fail to establish new connections when joining or rejoining the cluster, thus leading to a denial of service (DoS) attack.

Remediation

Upgrade to a fixed release: - v1.28.1+rke2r1 - v1.27.5+rke2r1 - v1.26.8+rke2r1 - v1.25.13+rke2r1 - 1.24.17+rke2r1

If you are using RKE2 1.27 or earlier, you must also add the parameter tls-san-security: true to the RKE2 configuration to enable enhanced security for the supervisor's TLS SAN list. This option defaults to true starting with RKE2 1.28.

Note that this flag changes the behavior of RKE2's supervisor listener. You should ensure that you configure node-external-ip on servers that will be connected to via an external IP, and add tls-san entries for any load-balancers or VIP addresses that will be associated with the supervisor port. External IPs and load-balancer/VIP addresses will no longer be added to the supervisor certificate's SAN list unless explicitly configured.

Mitigation

If you cannot upgrade to a fixed release, the certificate can be "frozen" by running the following command against the cluster:

shell kubectl annotate secret -n kube-system rke2-serving listener.cattle.io/static=true

⚠️ IMPORTANT CAUTION: Note that this mitigation will prevent the certificate from adding new SAN entries when servers join the cluster, and automatically renewing itself when it is about to expire. If you do this, you should delete the annotation when adding new servers to the cluster, or when the certificate is within 90 days of expiring, so that it can be updated. Once that is done, you can freeze it again.

Affected certificates can be reset by performing the following steps: Run kubectl delete secret -n kube-system rke2-serving Delete /var/lib/rancher/rke2/server/tls/dynamic-cert.json from all servers, and restart the rke2-server service.

Background

The RKE2 supervisor listens on port TCP 9345 and uses the rancher/dynamiclistener library to dynamically generate TLS certificates that contain TLS Subject Alternative Names (SAN) for any host name or IP address requested by a client. This is done to allow servers and external load-balancers to be added to the cluster without the administrator having to explicitly know and configure in advance a fixed list of endpoints that the supervisor may be hosted at.

The library allows the embedding application to configure a callback that is used to filter addresses requested by clients; but this was not previously implemented in RKE2.

For more information

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 RKE2 repository. - Verify with our support matrix and product support lifecycle.

Impact A vulnerability was identified in which users with update privileges on a namespace, can move that namespace into a project they don't have access to. After the namespace transfer is completed, their previous permissions are still preserved, which enables them to gain access to project-specific resources (such as project secrets). In addition, resources in the namespace will now count toward the quota limit of the new project, potentially causing availability issues.

User with roles Project Owner and Project Member on the source project can exploit this vulnerability; however, this would also apply to custom roles with similar privileges.

The patched version include an improved RBAC mechanism, which checks if the user has the correct permissions before the namespace move takes place.

Patches Patched versions include releases 2.6.13, 2.7.4 and later versions.

Workarounds There is no direct mitigation besides updating Rancher to a patched version.

For more information 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 Multiple Cross-Site Scripting (XSS) vulnerabilities have been identified in the Rancher UI. Cross-Site scripting allows a malicious user to inject code that is executed within another user's browser, allowing the attacker to steal sensitive information, manipulate web content, or perform other malicious activities on behalf of the victims. This could result in a user with write access to the affected areas being able to act on behalf of an administrator, once an administrator opens the affected web page.

The affected areas include the Projects/Namespaces and Auth Provider sections. The attacker needs to be authenticated and have write access to those features in order to exploit the vulnerabilities. Some of the permissions (roles) required are:

- Project Owner. - Restricted Admin. - Configure Authentication. - Administrator. - Custom RBAC Role that provides write access on Projects or External Authentication Providers.

For users that suspect this vulnerability may have targeted their Rancher instance, we recommend rotating all API Keys and Kubeconfig tokens.

It's also advised to review logs and possibly rotate credentials stored as secrets in Rancher and downstream cluster, if you believe that users' credentials to access Rancher and its clusters might have been compromised.

Patches Patched versions include releases 2.6.13, 2.7.4 and later versions.

Workarounds There is no direct mitigation besides updating Rancher to a patched version.

Credits We would like to recognize and thank @bybit-sec for the responsible disclosure of this security issue.

For more information 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 bug has been identified in which permission changes in Azure AD are not reflected to users while they are logged in the Rancher UI. This would cause the users to retain their previous permissions in Rancher, even if they change groups on Azure AD, for example, to a lower privileged group, or are removed from a group, thus retaining their access to Rancher instead of losing it.

Impact This issue only affects Rancher instances with Azure AD integration enabled, regardless of the automatically refreshing settings which are enabled by default. The users that obtained a token (or kubeconfig) to access Rancher through the following sessions are affected by this issue: 1) Users using the Rancher UI. 2) Users using kubectl based on a kubeconfig downloaded through the Rancher UI. 3) Tokens created via the Rancher UI Create API Key feature.

Note that the permission caching is persisted even when the Rancher Manager pod is restarted. The only way for a user to get the new permissions is to logout and login again.

Patches Patched versions include releases 2.6.13, 2.7.4 and later versions.

For more information 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.

The Service Location Protocol (SLP, RFC 2608) allows an unauthenticated, remote attacker to register arbitrary services. This could allow the attacker to use spoofed UDP traffic to conduct a denial-of-service attack with a significant amplification factor.

An Incorrect Default Permissions vulnerability in saphanabootstrap-formula of SUSE Linux Enterprise Module for SAP Applications 15-SP1, SUSE Linux Enterprise Server for SAP 12-SP5; openSUSE Leap 15.4 allows local attackers to escalate to root by manipulating the sudo configuration that is created. This issue affects: SUSE Linux Enterprise Module for SAP Applications 15-SP1 saphanabootstrap-formula versions prior to 0.13.1+git.1667812208.4db963e. SUSE Linux Enterprise Server for SAP 12-SP5 saphanabootstrap-formula versions prior to 0.13.1+git.1667812208.4db963e. openSUSE Leap 15.4 saphanabootstrap-formula versions prior to 0.13.1+git.1667812208.4db963e.

A Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in SUSE Rancher allows remote attackers to cause denial of service by supplying specially crafted git credentials. This issue affects: SUSE Rancher wrangler version 0.7.3 and prior versions; wrangler version 0.8.4 and prior versions; wrangler version 1.0.0 and prior versions.

A Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in SUSE Rancher allows code execution for user with the ability to add an untrusted Helm catalog or modifying the URL configuration used to download KDM (only admin users by default) This issue affects: SUSE Rancher Rancher versions prior to 2.5.17; Rancher versions prior to 2.6.10; Rancher versions prior to 2.7.1.

A Missing Authorization vulnerability in of SUSE Rancher allows authenticated user to create an unauthorized shell pod and kubectl access in the local cluster This issue affects: SUSE Rancher Rancher versions prior to 2.5.17; Rancher versions prior to 2.6.10; Rancher versions prior to 2.7.1.

An Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in libzypp-plugin-appdata of SUSE Linux Enterprise Server for SAP 15-SP3; openSUSE Leap 15.4 allows attackers that can trick users to use specially crafted REPOALIAS, REPOTYPE or REPOMETADATAPATH settings to execute code as root. This issue affects: SUSE Linux Enterprise Server for SAP 15-SP3 libzypp-plugin-appdata versions prior to 1.0.1+git.20180426. openSUSE Leap 15.4 libzypp-plugin-appdata versions prior to 1.0.1+git.20180426.

A Incorrect Default Permissions vulnerability in rmt-server-regsharing service of SUSE Linux Enterprise Server for SAP 15, SUSE Linux Enterprise Server for SAP 15-SP1, SUSE Manager Server 4.1; openSUSE Leap 15.3, openSUSE Leap 15.4 allows local attackers with access to the rmt user to escalate to root. This issue affects: SUSE Linux Enterprise Server for SAP 15 rmt-server versions prior to 2.10. SUSE Linux Enterprise Server for SAP 15-SP1 rmt-server versions prior to 2.10. SUSE Manager Server 4.1 rmt-server versions prior to 2.10. openSUSE Leap 15.3 rmt-server versions prior to 2.10. openSUSE Leap 15.4 rmt-server versions prior to 2.10.

A Improper Privilege Management vulnerability in SUSE Rancher, allows users with access to the escalate verb on PRTBs to escalate permissions for any -promoted resource in any cluster. This issue affects: SUSE Rancher Rancher versions prior to 2.5.17; Rancher versions prior to 2.6.10.

A Missing Authentication for Critical Function vulnerability in spacewalk-java of SUSE Manager Server 4.1, SUSE Manager Server 4.2 allows remote attackers to easily exhaust available disk resources leading to DoS. This issue affects: SUSE Manager Server 4.1 spacewalk-java versions prior to 4.1.46. SUSE Manager Server 4.2 spacewalk-java versions prior to 4.2.37.