Skip to main content

Security Advisories

Security advisories supplement security bulletins, providing additional details regarding vulnerabilities and offering remediation steps.

Refer to the Archived Security Advisories page for a list of addressed security advisories.

tip

Stay informed and subscribe to receive updates when new security advisories are published.

Security Advisory 024 - eMudhra Certificate Authority Compromise (TLS Trust Store Exposure)​

  • Release Date: October 21, 2026
  • Last Updated: November 9, 2026
  • Severity: High
  • CVSS Score: 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)
  • CVEs: CVE-2026-111943

Summary​

The private keys of eight eMudhra intermediate Certificate Authority (CA) certificates have been found to be recoverable by anyone, due to a key-generation flaw during their creation in April 2025. These intermediates chain to two publicly trusted roots: emSign ECC Root CA - G3 and AAA Certificate Services (the legacy Comodo/Sectigo root, which cross-signs the same keys).

An attacker holding one of these keys can issue a fraudulent X.509 certificate for any hostname. Any TLS client that still trusts one of these roots, and that an attacker can position themselves to intercept, will accept the forged certificate as valid. This enables an attacker-in-the-middle to impersonate a TLS endpoint and compromise the confidentiality and integrity of the connection, regardless of which CA the legitimate endpoint uses.

Affected Deployments​

All Palette deployment models are affected: MTSaaS and DSaaS, self-hosted Palette Enterprise and VerteX, workload clusters on cloud infrastructure (EKS, AKS, GKE) and PXK, RKE2, and K3s clusters managed through Palette, and edge clusters.

The exposure is narrow and client-side only.

  • Not affected:
    • Inbound and serving traffic. When a Palette deployment acts as a server, such as the console or an API endpoint, it presents its own certificate and consults no trust store. The compromised roots play no part.
    • Internal traffic between management-plane components. These connections authenticate with private, platform-issued certificates (pinned mutual TLS), not the public system trust store, so the compromised roots are not consulted.
    • Palette's own certificates. By default Palette does not use certificates issued by these CAs.
  • Affected:
    • outbound client connections where a Palette component validates the other end's certificate against a trust store that still trusts the compromised roots. An attacker able to intercept such a connection could present a forged certificate and have it accepted.

Impact​

Where an attacker holds a leaked key and an interception position, successful exploitation could allow them to:

  • Intercept and alter the edge-to-management control channel, including theft of the cluster service authentication token.
  • Impersonate the management plane and inject control responses to an edge or on-premises cluster.
  • Intercept container image pulls on affected nodes, which can lead to a malicious image and node-level code execution.
  • Intercept other outbound TLS connections that rely on the system trust store, exposing credentials or data carried on them.

Unauthenticated exploitation of a Palette endpoint is not possible through this issue; it requires both a leaked key and a network interception position.

a) Palette & VerteX Enterprise: Upgrade to a patched version when one is available for your release. Refer to Mitigation Status for the patched versions.

b) Workload Clusters: Patch all underlying host operating systems used in:

  • Kubernetes clusters
  • Managed node pools
  • Edge and on-prem deployments

For guidance on patching cluster nodes, refer to the OS Patching documentation.

c) Spectro Cloud patches multi-tenant SaaS and dedicated SaaS environments. Multi-tenant SaaS requires no action. Spectro Cloud upgrades each dedicated SaaS instance to the patched version for its release line in an agreed maintenance window. Contact your Spectro Cloud representative to confirm your window.

d) Customers are advised to monitor and audit outbound connections and watch for anomalous activities.

Mitigation Status​

Spectro Cloud updates this advisory as each patch is released.

Palette and VerteX Releases​

The following table lists the patch status of each Palette and VerteX version, what each version includes, and the deployments where each version is available. Spectro Cloud upgrades multi-tenant SaaS for all tenants at once. Each dedicated SaaS instance stays on its release line until Spectro Cloud upgrades it in a maintenance window agreed with you. In the Dedicated SaaS column, Available means that you can schedule the upgrade to that version.

VersionIncludesMulti-Tenant SaaSDedicated SaaSPalette and VerteX Management Appliances
4.10.34Rebuilt the remaining Palette and VerteX 4.10 images. Includes all patches from 4.10.33.ReleasedAvailableNot yet released
4.10.33Rebuilt most Palette and VerteX 4.10 images with updated trust stores.ReleasedNot applicableReleased
4.9.66Rebuilt the Palette and VerteX 4.9 images with updated trust stores.Not applicableAvailableNot yet released
4.8.74Rebuilt the Palette and VerteX 4.8 images with updated trust stores.Not applicableAvailableReleased

Kubernetes Versions and Packs​

The following table lists the patch status of Kubernetes versions and packs.

ComponentStatus
Kubernetes versionsNot yet released
Verified packs with upstream fixesNot yet released

Edge Hosts​

Provider images and Edge installer ISOs that you build with one of the following CanvOS versions no longer trust the affected root certificates: 4.10.11 or later, 4.9.44 or a later 4.9 version, or 4.8.32 or a later 4.8 version. Appliance mode Edge hosts that use images built with an earlier CanvOS version can use a workaround to remove the affected root certificates from the host trust store. The workaround applies to hosts that run Ubuntu, SUSE Linux Enterprise Micro, Red Hat Enterprise Linux, or Rocky Linux. Refer to Troubleshooting - Edge for the steps.

References​

Security Advisory 018 - Multiple Container Runtime Vulnerabilities​

Overview​

Multiple vulnerabilities have been identified in containerd that could allow attackers to achieve remote code execution, privilege escalation, information disclosure, denial of service, and bypass Kubernetes security controls.

The vulnerabilities affect multiple container runtime components responsible for image management, container restoration, resource access controls, logging, and workload lifecycle operations.

CVE-2026-50195 - Improper Validation During Container Restoration​

  • Severity: HIGH
  • CVSS Score: 8.8

A flaw in container restoration handling may allow a malicious actor with the ability to influence restoration operations to affect other workloads on the same node. Under certain conditions, successful exploitation could result in unauthorized code execution within other workloads.

Impact​

  • Cross-pod code execution
  • Compromise of workloads sharing a node
  • Potential lateral movement within a Kubernetes cluster

CVE-2026-53488 - Improper Handling of Container Image Metadata​

  • Severity: HIGH
  • CVSS Score: 8.3

A vulnerability in the processing of container image metadata could allow a specially crafted image to trigger unintended actions on an affected host. Successful exploitation may result in elevated access on the node.

Impact​

  • Arbitrary host command execution
  • Potential node compromise
  • Escalation from image author to node-level access

None of the annotations required for exploitation are enabled by default on Palette deployments or workload clusters.

CVE-2026-53492 - Improper Validation of Restoration Metadata​

  • Severity: MEDIUM
  • CVSS Score: 6.8

A vulnerability affecting container restoration workflows may allow security controls governing device and resource access to be bypassed. Under certain circumstances, an attacker could gain access to resources that would otherwise be restricted.

Impact​

  • Unauthorized device access
  • Host mount injection
  • Bypass of Kubernetes device enforcement policies

CVE-2026-53489 - Arbitrary Host File Read via Symlinked Log Paths​

  • Severity: MEDIUM
  • CVSS Score: 6.5

A flaw in restoration-related file handling may allow unauthorized access to information stored on the host system. Successful exploitation could result in exposure of sensitive data.

Impact​

  • Arbitrary host file read
  • Exposure of sensitive configuration or credential data

CVE-2026-47262 - Resource Exhaustion Leading to Service Disruption​

  • Severity: MEDIUM
  • CVSS Score: 6.8

A vulnerability in image processing may allow an attacker to cause excessive resource consumption on an affected node. Successful exploitation could disrupt container management services and impact workload availability.

Impact​

  • Node-level denial of service
  • Container startup and management failures
  • Potential disruption of all workloads on the affected node

Affected Deployments​

  • Workload Clusters
    • Managed Kubernetes clusters (EKS, AKS, GKE)
    • PXK clusters managed through Palette
    • RKE2 and K3s clusters managed through Palette
    • Palette Enterprise and Palette VerteX deployments
  • Palette Enterprise & Palette VerteX Deployments
    • SaaS deployments
    • Self hosted deployments

Mitigation and Remediation​

  • SaaS deployments
    • Multi-tenant and dedicated SaaS clusters are being reviewed and patched as part of the standard update.
  • Self-Hosted Palette Enterprise and Palette VerteX Deployments
    • Self-hosted installations deployed on managed Kubernetes clusters, such as EKS, should update the clusters with the fixes provided by the cloud vendor.
    • Deployments on customer infrastructure must upgrade to Kubernetes versions that include the patches.
    • Patched versions of the Palette Enterprise and Palette VerteX appliances downloaded from Artifact Studio will be available in an upcoming release.
  • Workload Clusters
    • Managed Kubernetes clusters (AKS, EKS, GKE) managed by Palette or VerteX should be updated with patches from the cloud vendor as soon as they are available. This requires patching the OS on cluster nodes. For guidance on patching cluster nodes, refer to OS Patching.
    • Patched OS images for other clusters will be available in an upcoming release. We advise all customers to upgrade to the latest Kubernetes patch versions as soon as they are available.
    • Patches for Edge clusters will be available in an upcoming release. We advise all customers to upgrade the clusters to the patched versions as soon as possible.

Until you can deploy patches, consider the following mitigations:

  • Restrict the use of checkpoint and restore functionality to trusted administrators.
  • Disable checkpoint and restore if it is not required.
  • Disable the Container Device Interface (CDI) where device injection capabilities are not needed.
  • Enforce image provenance and only allow trusted container images from approved registries.
  • Implement image signing and verification controls.
  • Restrict node access and monitor for unexpected container restores.
  • Audit Kubernetes workloads for unauthorized device assignments, host mounts, and privileged execution.
  • Monitor containerd processes for abnormal memory consumption and unexpected restarts.

References​

Security Advisory 017 - Improper Access Control for Debugging and Profiling Interface in Stylus​

  • Release Date: June 4, 2026
  • Last Updated: June 15, 2026
  • Severity: HIGH

Summary​

Spectro Cloud has identified an issue where the Go debugging and profiling interface (debug/pprof) may be accessible on certain ports on Stylus (Palette Edge agent) deployments. The exposed interface is intended for application debugging and performance analysis. If accessible, it can provide detailed runtime information about the process, including goroutine stacks, heap information, memory allocations, thread information, and CPU profiling data.

Spectro Cloud is not aware of any evidence of active exploitation in customer environments at the time of publication. Spectro Cloud has identified the root cause and is developing a fix.

Affected Deployments​

Impact​

Successful access to the exposed debug/pprof endpoint may allow an authenticated or network-adjacent attacker to obtain sensitive runtime information, including:

  • Goroutine stack traces
  • Memory allocation and heap information
  • Thread creation statistics
  • Process execution traces
  • Command-line runtime parameters

While the interface does not directly provide remote code execution, exposed profiling information may assist attackers in reconnaissance, vulnerability research, denial-of-service analysis, or chaining with other vulnerabilities. The risk is limited to environments where the endpoint is reachable over the network.

Customers are encouraged to take the following actions:

  • Restrict network access to affected ports to required Kubernetes control-plane components only.
  • Review firewall rules, security groups, and network policies to ensure the endpoint is not accessible from untrusted networks.
  • Block direct user or workload access where possible.
  • Apply network segmentation controls.
  • Monitor for unexpected access attempts to /debug/pprof/* endpoints.
  • Upgrade to a fixed release once remediation becomes available.

Fix Availability​

Palette and Palette VerteX version 4.9.16 has addressed this security advisory.

Additionally, this remediation was backported to Palette 4.8.61 and 4.7.45 releases.

Security Advisory 016 - Upload Service Authentication Bypass​

  • Release Date: June 4, 2026
  • Last Updated: June 15, 2026
  • Severity: CRITICAL

Summary​

Spectro Cloud has identified and remediated a vulnerability that could allow unauthenticated users to upload content bundles to Edge hosts under certain conditions. The issue was corrected in Palette version 4.9.14.

The vulnerability resulted from an authentication validation logic error that could permit requests that did not provide valid authentication credentials to bypass intended access controls for the upload endpoint.

Affected Deployments​

This issue affects all multi-tenant SaaS, dedicated SaaS, self-hosted, and appliance-based deployments earlier than version 4.9.14.

Impact​

A successful exploitation of this vulnerability could have allowed an unauthenticated actor with network access to the affected upload service endpoint to upload content bundles to the Edge host. Depending on the deployment configuration and network exposure of the affected endpoint, an attacker may have been able to write files to locations used by the content management service. This could result in unauthorized modification of content stored on the affected Edge system.

Spectro Cloud has not identified evidence of active exploitation of this vulnerability in customer environments at the time of this advisory.

Fix Availability​

This issue has been fully remediated in release 4.9.14 for the Spectro Cloud managed SaaS solution.

Additionally, this remediation was backported to Palette 4.8.61 and 4.7.45 releases.

Customers are encouraged to take the following actions:

  • Upgrade self-hosted deployments to 4.9.14 or a later as soon as possible.
  • Upgrade both the Palette software and the Edge host components. Ensure that affected Edge hosts are upgraded to the corresponding Stylus Agent version (4.9.10) containing the fix.
  • Review system and application logs for unexpected upload activity.

References​

Security Advisory 015 - Exposure of Cluster-Scoped Service Credentials Through Manifest Endpoints​

  • Release Date: June 3, 2026
  • Last Updated: June 15, 2026
  • Severity: HIGH

Summary​

Spectro Cloud has identified a security vulnerability affecting specific manifest-related API endpoints, which, under certain conditions, may expose cluster-scoped service credentials.

The impact is architecturally isolated. Service credentials are restricted tokens that do not permit direct access to any management plane APIs. The issue is confined to the affected cluster, with no evidence of cross-tenant exposure. Spectro Cloud confirms that no administrative kubeconfig assets are exposed by this issue.

Spectro Cloud is actively developing and validating remediation measures to enhance protections around the affected endpoints and their credential handling.

Affected Deployments​

All Palette Enterprise and Palette VerteX deployment methods (multi-tenant SaaS, dedicated SaaS, and self-hosted) are affected, specifically:

  • Clusters originally created outside of Palette and subsequently imported into or taken over by Palette
  • Private Cloud Gateways (PCGs) created using the Palette CLI

All clusters created and continuously managed by Palette (workload clusters) are not affected.

Impact​

Under specific conditions, the exposure of cluster-scoped service credentials could grant an attacker limited access to a subset of cluster-associated services. Crucially, this vulnerability does not provide direct access to core management functions or administrative assets.

Several existing, in-place controls significantly reduce the practical impact of this issue:

  • Credentials are scoped and limited to a single cluster.
  • Authorization enforcement prevents access outside the associated environment.
  • Credentials are automatically invalidated upon deletion of the associated cluster or PCG.

Fix Availability​

Palette and Palette VerteX version 4.9.16 has addressed this security advisory. Self-hosted customers are advised to upgrade to Palette version 4.9.16 or later.

Additionally, this remediation was backported to Palette 4.8.61 and 4.7.45 releases.

Customers are encouraged to implement the following actions to further reduce potential exposure:

  • Restrict network access to management interfaces and APIs.
  • Limit access exclusively to trusted administrative networks.
  • Actively monitor for unexpected or anomalous API activity.
  • Adhere to standard credential and cluster lifecycle management best practices.

Security Advisory 014 - Linux Kernel "Dirty Frag" and "Fragnesia" Privilege Escalation Vulnerabilities​

Summary​

Spectro Cloud is aware of three high-severity Linux kernel vulnerabilities that allow local privilege escalation through improper handling of fragmented network packet data:

These flaws allow an attacker to modify protected memory regions during packet decryption, potentially overwriting sensitive data and escalating privileges to root.

A public proof-of-concept (PoC) exploit is available, which increases the risk of exploitation on unpatched systems.

Applicable Systems​

The vulnerabilities affect Linux kernel versions 4.10 through 7.x, with version-specific exposure varying by distribution. Systems with ESP/IPsec, RxRPC, or related networking modules available are especially at risk.

Spectro Cloud's platform components do not require these kernel modules and do not need them to be loaded. Workload clusters also do not need these modules to function. However, customer-managed nodes and workloads running affected Linux kernels can be modified to load the affected kernel modules even if not enabled by default.

Impact​

An attacker with local access to a vulnerable system may:

  • Escalate privileges to root
  • Modify protected files or memory
  • Compromise the underlying host from a containerized workload

Container isolation does not protect against this vulnerability, as exploitation targets the host kernel directly. Workloads with access to specific socket types or elevated capabilities are at higher risk.

Spectro Cloud strongly recommends patching all underlying host operating systems used in:

  • Kubernetes clusters
  • Managed node pools
  • Edge and on-prem deployments

For guidance on patching cluster nodes, refer to OS Patching.

Mitigation​

  1. Apply vendor kernel patches immediately and upgrade to patched kernel versions where possible.
  2. Reboot nodes after patching to unload vulnerable kernel components.
  3. Apply runtime security controls to restrict unnecessary kernel network interfaces.

References​

Security Advisory 013 - Linux Kernel "Copy Fail" Privilege Escalation Vulnerability​

  • Release Date: May 4, 2026
  • Last Updated: May 4, 2026
  • Severity: HIGH
  • CVE: CVE-2026-31431

Summary​

Spectro Cloud is aware of a high-severity Linux kernel vulnerability, CVE-2026-31431. This issue allows an unprivileged local user to escalate privileges to root on affected systems.

The vulnerability impacts a wide range of Linux distributions commonly used in cloud, Kubernetes, and containerized environments.

A public proof-of-concept (PoC) exploit is available, and the vulnerability has been observed in active exploitation scenarios.

Applicable Systems​

The issue is reported in the Linux kernel Crypto subsystem (algif_aead / AF_ALG interface).

Spectro Cloud platform components do not require this kernel module and do not need this to be loaded. Kubernetes workload clusters also do not need this module to function.

However, customer-managed nodes and workloads running affected Linux kernels can be modified to load the affected kernel module even if not enabled by default.

Impact​

Successful exploitation allows:

  • Local privilege escalation to root
  • Potential container escape
  • Compromise of multi-tenant Kubernetes environments
  • Lateral movement across nodes and workloads

Spectro Cloud strongly recommends patching all underlying host operating systems used in:

  • Kubernetes clusters
  • Managed node pools
  • Edge and on-prem deployments

For guidance on patching cluster nodes, refer to the OS Patching documentation.

Mitigation​

  1. Apply vendor kernel patches immediately
    • Upgrade to patched kernel versions where available
  2. Reboot nodes after patching
    • Ensures vulnerable kernel components are unloaded
  3. Apply temporary mitigations if patching is delayed
    • Disable or block the algif_aead module
    • Restrict AF_ALG access

References​

Security Advisory 012 - Nginx Ingress Comment-Based Configuration Injection Vulnerability​

  • Release Date: March 23, 2026
  • Last Updated: April 15, 2026
  • Severity: HIGH (CVSS 8.8)
  • CVEs: CVE-2026-4342

Summary​

A security issue was discovered in ingress-nginx, where certain combinations of Ingress annotations can be used to inject configurations into Nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller and the disclosure of Secrets accessible to the controller. In the default ingress-nginx installation, the controller can access all Secrets cluster-wide.

Affected Versions​

The following Nginx versions are affected by CVE-2026-4342:

  • v1.15.0
  • v1.14.0 - v1.14.4
  • v1.13.0 - v1.13.8

Affected Deployments​

  • Palette Enterprise and Palette VerteX environments - All multi-tenant SaaS, dedicated SaaS, self-hosted, and appliance-based deployments earlier than version 4.8.40.
  • Workload Clusters - All workload clusters using the Nginx pack with an affected Nginx version.

Impact​

An attacker with the ability to create or modify Ingress resources can exploit this vulnerability to inject arbitrary Nginx configurations, leading to remote code execution in the ingress-nginx controller and the potential exposure of Kubernetes Secrets.

Fix Availability​

  • Multi-Tenant and Dedicated SaaS Deployments - All SaaS environments have been patched as part of the standard update process. No action is required.
  • Self-Hosted Deployments - Palette version 4.8.51 has the fixed version of the ingress-nginx controller. Users should update their environments to this version.
  • Workload Clusters - Upgrade your workload clusters to use the latest version of the Nginx pack. If using vendor-managed ingress add-ons, follow your cloud provider's patch guidance.

Mitigation​

Restrict Ingress creation to trusted users, disable or block unsafe annotations (such as snippet directives), and enforce admission policies to validate Ingress configurations. Additionally, minimize ingress-nginx controller privileges, limit its access to Secrets, and monitor for suspicious Ingress changes.

Resources​

Security Advisory 010 - Nginx Ingress Configuration Injection Vulnerability​

  • Release Date: March 10, 2026
  • Last Updated: March 10, 2026
  • Severity: HIGH
  • CVEs: CVE-2026-3288

Summary​

A vulnerability has been identified in the Kubernetes ingress-nginx controller where the nginx.ingress.kubernetes.io/rewrite-target Ingress annotation can be exploited to inject arbitrary Nginx configuration directives.

Successful exploitation may result in:

  • Arbitrary code execution in the ingress-nginx controller context.
  • Disclosure of Kubernetes Secrets accessible to the controller.
  • Compromise of workloads exposed through the ingress controller.

This vulnerability only affects environments using the ingress-nginx controller.

Affected Deployments​

  • All workload clusters using the Nginx pack.
  • All Palette Enterprise and Palette VerteX deployment methods (multi-tenant SaaS, dedicated SaaS, and self-hosted).

Impact​

An attacker with the ability to create or modify an Ingress resource may be able to:

  • Inject malicious configuration into Nginx.
  • Execute arbitrary code within the ingress controller pod.
  • Access or exfiltrate Kubernetes Secrets accessible to the controller (potentially cluster-wide).

The risk is higher in environments where:

  • Users have Ingress write privileges.
  • The ingress controller has broad RBAC permissions.
  • Secrets are accessible across namespaces.

Multi-tenant and Dedicated SaaS Deployments​

Multi-tenant & managed Dedicated SaaS clusters have been patched as part of the standard update process to Palette version 4.8.47.

Self-Hosted Palette Deployments​

The Nginx ingress controller versions 1.13.8, 1.14.4, and 1.15.0 are now available.

Workload Clusters​

Apply ingress-nginx updates as soon as patched images are available. If using vendor-managed ingress add-ons, follow cloud provider patch guidance.

Mitigation​

  • Apply a temporary policy to block nginx.ingress.kubernetes.io/rewrite-target via admission control until patched for workload clusters using the vulnerable version.
  • Restrict Ingress creation permissions to trusted administrators.
  • Reduce ingress controller RBAC permissions where feasible.

Resources​

Security Advisory 009 - crypto/tls TLS Session Resumption​

  • Release Date: February 5, 2026
  • Last Updated: February 18, 2026
  • Severity: CRITICAL
  • CVEs: CVE-2025-68121

Summary​

CVE-2025-68121 is a critical security vulnerability in the Go standard library (crypto/tls) that may allow unintended TLS session resumption when certificate validation configuration changes between connections. Under specific conditions, an attacker may resume a previously established TLS session even when updated certificate validation settings should cause the connection to fail.

Affected Deployments​

  • All Palette Enterprise and Palette VerteX deployment methods (multi-tenant SaaS, dedicated SaaS, and self-hosted)
  • All workload clusters

Impact​

Successful exploitation may allow:

  • Bypassing updated certificate validation policies
  • Resuming unauthorized TLS sessions
  • Compromising the confidentiality and integrity of session data

This can affect service-to-service communication and API traffic, depending on how the services use crypto/tls and resume sessions.

Fix Availability​

Palette version 4.8.38 includes fixes for this vulnerability in both core images and third-party images, where available. Refer to the Release Notes page for further details.

Mitigations​

Until a fix is available, customers may mitigate risk by monitoring and auditing controls to detect any unauthorized or unexpected changes to root Certificate Authority (CA) or client CA bundles, including updates to Kubernetes Secrets and ConfigMaps.

Resources​

Security Advisory 008 - Nginx Ingress Vulnerabilities​

Summary​

On February 3, 2026, Spectro Cloud became aware of and is tracking the coordinated disclosure of multiple vulnerabilities recently disclosed in the Nginx ingress controller versions 1.13.0–1.13.6 and 1.14.0–1.14.2. These vulnerabilities were fixed in versions 1.13.7 and 1.14.3.

The following vulnerabilities do not affect our products, as we do not use these annotations:

  • CVE-2026-1580 - (auth-method annotation)
  • CVE-2026-24512 - (rules.http.paths.path)
  • CVE-2026-24513 - (auth-url protection)
  • CVE-2025-15566 (auth-proxy-set-headers)

The following vulnerability does impact Palette Enterprise and Palette VerteX deployments:

  • CVE-2026-24514 - Admission Controller denial of service

Nginx controller has been deprecated by the upstream provider, and we are in the process of migrating to Traefik ingress controller. Until the migration to Traefik ingress is complete, we will be upgrading Nginx controller to version 1.13.7, which will remediate this vulnerability.

Palette version 4.8.27 uses Nginx controller version 1.13.7.

Affected Deployments​

  1. Workload Clusters

    • All clusters using the Nginx pack.

  2. Palette Enterprise and Palette VerteX deployments

    • CVE-2026-24514 affects all Palette Enterprise and Palette VerteX deployment methods (multi-tenant SaaS, dedicated SaaS, and self-hosted), as well as all workload clusters using the Nginx pack.

We recommend taking the following actions to remediate CVE-2026-2451.

Multi-tenant and Dedicated SaaS Deployments​

No action necessary. Deployments will be patched as part of the standard update process.

Palette Enterprise or VerteX Installed with Helm Charts​

If you have any instances of Palette enterprise or VerteX installed via Helm Charts with the affected version of the ingress-nginx-controller DaemonSet, you must update it to version 1.13.7. Follow the steps below to download the updated version of the component and update your instance.

  1. Use the kubeconfig file and kubectl tool to access your Palette enterprise or VerteX cluster. Refer to the Access Cluster with CLI guide for more information.

  2. Check the image used by the ingress-nginx-controller DaemonSet in the ingress-nginx namespace.

    kubectl get daemonset ingress-nginx-controller --namespace ingress-nginx --output yaml | grep 'image:'

  3. Once you identify the image, update its tag to v1.13.7. You can use the kubectl set image command to update the image.

  • If the ingress-nginx-controller DaemonSet is using the image gcr.io/spectro-images-public/release-fips/ingress-nginx/controller:v1.13.3, update it to gcr.io/spectro-images-public/release-fips/ingress-nginx/controller:v1.13.7. Replace <container-name> with the name of the container.

    kubectl set image daemonset/ingress-nginx-controller <container-name>=gcr.io/spectro-images-public/release-fips/ingress-nginx/controller:v1.13.7 --namespace ingress-nginx

  • If the ingress-nginx-controller DaemonSet is using the image us-docker.pkg.dev/palette-images/third-party/ingress-nginx/controller:v1.13.3, update it to us-docker.pkg.dev/palette-images/third-party/ingress-nginx/controller:v1.13.7. Replace <container-name> with the name of the container.

    kubectl set image daemonset/ingress-nginx-controller <container-name>=us-docker.pkg.dev/palette-images/third-party/ingress-nginx/controller:v1.13.7 --namespace ingress-nginx

Palette Enterprise or VerteX Installed with the Palette CLI​

If you have any instances of Palette enterprise or VerteX installed via the Palette CLI with the affected version of the ingress-nginx-controller DaemonSet, you must update it to version 1.13.7. Follow the steps below to download the updated version of the component and update your instance.

  1. Use the kubeconfig file and kubectl tool to access your Palette enterprise or VerteX cluster. Refer to the Access Cluster with CLI guide for more information.

  2. Scale down the palette-controller-manager deployment to zero replicas in the cluster-mgmt-* namespace, replacing * with the suffix associated with your namespace.

    kubectl scale deployment palette-controller-manager --replicas=0 --namespace cluster-mgmt-*

  3. Scale down the cluster-management-agent deployment to zero replicas in the cluster-mgmt-* namespace, replacing * with the suffix associated with your namespace.

    kubectl scale deployment cluster-management-agent --replicas=0 --namespace cluster-mgmt-*

  4. Confirm that both deployments have been scaled down to zero replicas. Replace * with the suffix associated with your namespace.

    kubectl get deployments --namespace cluster-mgmt-*

  5. Check the image used by the ingress-nginx-controller DaemonSet in the ingress-nginx namespace.

    kubectl get daemonset ingress-nginx-controller --namespace ingress-nginx --output yaml | grep 'image:'

  6. Once you identify the image, update its tag to v1.13.7. You can use the kubectl set image command to update the image.

  • If the ingress-nginx-controller DaemonSet is using the image gcr.io/spectro-images-public/release-fips/ingress-nginx/controller:v1.13.3, update it to gcr.io/spectro-images-public/release-fips/ingress-nginx/controller:v1.13.7. Replace <container-name> with the name of the container.

    kubectl set image daemonset/ingress-nginx-controller <container-name>=gcr.io/spectro-images-public/release-fips/ingress-nginx/controller:v1.13.7 --namespace ingress-nginx

  • If the ingress-nginx-controller DaemonSet is using the image us-docker.pkg.dev/palette-images/third-party/ingress-nginx/controller:v1.13.3, update it to us-docker.pkg.dev/palette-images/third-party/ingress-nginx/controller:v1.13.7. Replace <container-name> with the name of the container.

    kubectl set image daemonset/ingress-nginx-controller <container-name>=us-docker.pkg.dev/palette-images/third-party/ingress-nginx/controller:v1.13.7 --namespace ingress-nginx

Airgap Palette Enterprise or VerteX​

If you have any airgapped instances of Palette enterprise or VerteX using the affected version of the ingress-nginx-controller DaemonSet, you must update it to version 1.13.7. Follow the steps below to download the updated version of the component and update your instance.

  1. Contact your Palette support representative to obtain the airgap-palette-nginx binary version 1.13.7. Ensure the SHA of the binary is ea6d7f28a24e100998ea382ab2d206f81dc33776ac98091815e794fb35b215ce. Once obtained, upload the airgap-palette-nginx binary to the registry. Follow the Usage Instructions guide for detailed steps on downloading and installing the binary.

  2. Log in to the Palette system console.

  3. From the left Main Menu, select Administration > Pack Registries. Then, next to the registry, click the three-dot button > Sync. Wait for the registry synchronization to complete.

  4. Use the kubeconfig file and kubectl tool to access your Palette enterprise cluster. Refer to the Access Cluster with CLI guide for more information.

  5. Scale down the palette-controller-manager deployment to zero replicas in the cluster-mgmt-* namespace, replacing * with the suffix associated with your namespace.

    kubectl scale deployment palette-controller-manager --replicas=0 --namespace cluster-mgmt-*

  6. Scale down the cluster-management-agent deployment to zero replicas in the cluster-mgmt-* namespace, replacing * with the suffix associated with your namespace.

    kubectl scale deployment cluster-management-agent --replicas=0 --namespace cluster-mgmt-*

  7. Confirm that both deployments have been scaled down to zero replicas. Replace * with the suffix associated with your namespace.

    kubectl get deployments --namespace cluster-mgmt-*

  8. Check the image used by the ingress-nginx-controller DaemonSet in the ingress-nginx namespace.

    kubectl get daemonset ingress-nginx-controller --namespace ingress-nginx --output yaml | grep 'image:'

  9. Once you identify the image, update its tag to v1.13.7. You can use the kubectl set image command to update the image.

  • If the ingress-nginx-controller DaemonSet is using the image gcr.io/spectro-images-public/release-fips/ingress-nginx/controller:v1.13.3, update it to gcr.io/spectro-images-public/release-fips/ingress-nginx/controller:v1.13.7. Replace <container-name> with the name of the container.

    kubectl set image daemonset/ingress-nginx-controller <container-name>=gcr.io/spectro-images-public/release-fips/ingress-nginx/controller:v1.13.7 --namespace ingress-nginx

  • If the ingress-nginx-controller DaemonSet is using the image us-docker.pkg.dev/palette-images/third-party/ingress-nginx/controller:v1.13.3, update it to us-docker.pkg.dev/palette-images/third-party/ingress-nginx/controller:v1.13.7. Replace <container-name> with the name of the container.

    kubectl set image daemonset/ingress-nginx-controller <container-name>=us-docker.pkg.dev/palette-images/third-party/ingress-nginx/controller:v1.13.7 --namespace ingress-nginx

Airgap Workload Clusters Using the Nginx Pack​

If you have any airgap workload clusters using the affected version of the Nginx pack, you must update the cluster profile to version 1.13.7 of the Nginx pack. Follow the steps below to download the updated pack and modify your cluster profile.

  1. Contact your Palette support representative to obtain the airgap-pack-nginx binary version 1.13.7. Once obtained, upload the airgap-pack-nginx binary to the registry. Follow the Usage Instructions guide for detailed steps on downloading and installing the binary.

  2. Log in to the Palette system console.

  3. From the left main menu, select Administration > Pack Registries. Then, next to the registry, click the three-dot button > Sync. Wait for the registry synchronization to complete.

  4. Log in to the Palette console.

  5. Update all cluster profiles currently using the affected version of the Nginx pack. Refer to the Update a Cluster Profile guide for instructions on how to update a cluster profile.

  6. Apply the profile updates to all affected clusters. Refer to the Apply Profile Updates to Clusters guide to learn how to apply profile updates to clusters.

Resources​

For additional information, refer to the following GitHub Security Advisories:

Security Advisory 007- MongoDB zlib Compression Memory​

  • Release Date: December 26, 2025
  • Last Updated: December 29, 2025
  • Severity: Critical
  • CVEs: CVE-2025-14847

Summary​

A critical unauthenticated vulnerability (CVE-2025-14847) was discovered in MongoDB Server’s handling of zlib-compressed network traffic. Under certain conditions, a remote attacker can cause the server to include uninitialized heap memory in its responses. Because this memory is drawn directly from the MongoDB process, the exposed data may contain fragments of previously processed requests, internal state, or other sensitive information.

Exploitation requires no authentication. Any attacker with network access to a MongoDB instance that has compression enabled can potentially trigger the issue. As a result, internal process memory becomes observable to an external attacker, leading to unintended information disclosure.

Affected Versions​

The following MongoDB Server versions are affected by CVE-2025-14847 when network compression is enabled:

  • 3.6.x
  • 4.0.x
  • 4.2.x
  • 4.4.0 - 4.4.29
  • 5.0.0 - 5.0.31
  • 6.0.0 - 6.0.26
  • 7.0.0 - 7.0.26
  • 8.0.0 - 8.0.16
  • 8.2.0 - 8.2.2

Resolved Versions​

The vulnerability is resolved in the following MongoDB Server releases:

  • 4.4.30
  • 5.0.32
  • 6.0.27
  • 7.0.28
  • 8.0.17
  • 8.2.3

Mitigation​

Network-level isolation of MongoDB instances and restricting access to trusted internal components reduces exposure. Disabling network compression may further mitigate risk where feasible.

Impact for Spectro Cloud​

MongoDB is not directly exposed to the public internet in Palette Enterprise and Palette VerteX deployments. Consequently, this vulnerability is not exploitable under normal operating conditions. Exploitation would require a prior compromise that grants an attacker network-level access to the underlying infrastructure or cluster hosting the deployment.

While MongoDB has rated this vulnerability as critical, Spectro Cloud’s deployment architecture significantly limits the exploitation surface, resulting in a low practical risk to Palette Enterprise and VerteX customers.

Implementation Plan​

  • All managed SaaS instances have been upgraded to a version that includes the fix for this vulnerability. No further action is required for these environments.
  • All self-hosted Palette and VerteX deployments running the latest release currently use MongoDB 7.0.26 and will be upgraded to version 7.0.28.

This advisory will be updated to reflect availability of the fixes described above.

Resources​

Security Advisory 006.1 - Shai Hulud npm Supply Chain Attack - Supplemental Update​

  • Release Date: December 1, 2025
  • Last Updated: December 2, 2025
  • Severity: High

Summary​

Following our initial advisory regarding the Shai Hulud 2.0 supply-chain malware campaign on November 26, 2025, we are issuing the following supplemental update to provide additional transparency into our internal findings and response actions.

As part of our comprehensive, end-to-end investigation, we have identified limited areas of impact within internal development and operational systems. At this time, we have no evidence that any Spectro Cloud customer environments, products, or managed SaaS services have been compromised. However, out of an abundance of caution, we are proceeding with the same rigor applied to a confirmed incident to ensure the integrity of our entire ecosystem.

The activity observed is consistent with the broader industry-wide attack pattern associated with Shai Hulud 2.0, specifically targeting development workflows and supply-chain trust pathways.

Immediate Mitigation Actions Underway​

Our teams are working diligently to implement a comprehensive set of precautionary and containment measures. This includes rotating all credentials and secrets, reviewing our build and dependency processes, adding safeguards to strengthen our CI/CD workflows, and enhancing monitoring across our development and production systems. These steps are being taken out of an abundance of caution to ensure the continued security and integrity of our platform.

We will continue to monitor evolving intelligence from security researchers, collaborate with our partners, and expand our internal investigations as new indicators of compromise are published. This advisory will be updated with additional findings as the investigation progresses.

Resources​

Security Advisory 006 - Shai Hulud npm Supply Chain Attack​

  • Release Date: November 26, 2025
  • Last Updated: November 26, 2025
  • Severity: High

Summary​

On November 21, 2025, security researchers identified Shai Hulud 2.0, a newly uncovered strain of malware that has compromised more than 25,000 GitHub repositories. This variant introduces an advanced self-replicating architecture, enabling it to autonomously propagate across software projects and potentially embed itself within development workflows. Early analysis indicates that the malware is specifically engineered to exploit supply-chain trust mechanisms by modifying code artifacts at the repository level.

Spectro Cloud products are not dependent on any of the npm packages affected by the incident. However, because many customers integrate external CI/CD toolchains with Spectro Cloud products, a compromise of those toolchains could allow malicious changes to flow through automation. Customers should scan their applications and integrations to assess the impact of this issue.

Our security posture incorporates continuous scanning, automated policy enforcement, and rigorous supply-chain validation controls designed to detect and block malicious or tampered components before they enter our build or delivery pipelines. As part of our response, we are actively conducting comprehensive, end-to-end scans across all internal IT systems, developer environments, and managed SaaS deployments. These measures are ongoing, and we are prioritizing both accuracy and completeness in our investigation.

We will continue to monitor evolving intelligence from security researchers, collaborate with our partners, and expand our internal investigations as new indicators of compromise are published. This advisory will be updated with additional findings as the investigation progresses.

Resources​

Security Advisory 005 - runc Container Vulnerabilities Affecting Kubernetes Cluster Runtimes​

  • Release Date: November 5, 2025
  • Last Update: November 6, 2025
  • Severity: High
  • Applicable Deployments:
    • Workload Clusters:
      • cloud-managed clusters: EKS, GKE, and AKS
      • Kubernetes distributions: PXK, RKE2, and K3s
    • Palette deployments:
      • SaaS Palette
      • self-hosted Palette

Timeline​

  • November 5, 2025: First notified of vulnerabilities.

Summary​

The recently disclosed vulnerabilities in the runc container runtime involve unsafe handling of /proc writes during container initialization and mount operations. Attackers exploiting these vulnerabilities could cause runc to misdirect writes within /proc, potentially allowing:

  • Execution of privileged host actions (for example, triggering /proc/sysrq-trigger to crash or hang the host).
  • Read or write access to sensitive host information that would normally be masked.
  • Disabling of AppArmor or Security-Enhanced Linux (SELinux) confinement.
  • Modification of kernel parameters (for example, core_pattern).

Workload Clusters​

  • Update cloud-managed clusters (EKS, GKE, and AKS) integrated with Palette Enterprise or Palette VerteX with patches from their respective cloud providers as soon as they become available.
  • Patched OS images for other clusters will be available in future releases. Upgrade to the latest Kubernetes patch versions as soon as they are available.
  • A patch for Edge clusters will be available in future releases. Upgrade clusters to the patched versions as soon as they are available.

SaaS Palette Deployments​

No customer action is required. Multi-tenant and dedicated SaaS environments are being reviewed and patched as part of the standard update process. Continuous compliance scans are enabled to identify nodes with pending patches.

Self-Hosted Palette Deployments​

  • For Palette environments hosted on cloud-managed Kubernetes clusters (such as EKS), update the underlying clusters with patches provided by the respective cloud vendors.
  • For Palette environments deployed on customer-managed infrastructure, patched versions of Palette will be available in future releases. Upgrade your Palette environments to the patched versions as soon as they are available.
  • Patched Palette and VerteX appliance images downloaded from Artifact Studio will also be made available in future releases. Use the updated appliance images when deploying or upgrading Palette and VerteX instances.