Red Hat Linux Security Advisories & CVEs
4724 advisories tracked · Red Hat Security Data API · direct feeds checked every minute; rate-limited backstops use a safe source cadence
Android app · Google Play
Monitor Red Hat CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 34 official vendor sources and 160+ reviewed platform categories.
Security advisories for your Red Hat release
Pick your distribution release to see every advisory issued for it and its severity mix. Fixes ship as errata — keep the system patched. This is the release's advisory history, not a per-package scan.
Official source
Red Hat Security Data API
Red Hat Enterprise Linux errata (RHSA) via the official Red Hat Security Data API — CVE severity, CVSS and affected packages. A credential-free official source.
Latest Red Hat advisories
High [CVE-2026-54059] Denial of Service via crafted PCF font data
Pillow is a Python imaging library. Prior to 12.3.0, PIL/PcfFontFile.py _load_bitmaps() read glyph dimensions from the PCF METRICS section and passed them directly to Image.frombytes() without calling Image._decompression_bomb_check(), allowing crafted PCF font data to cause excessive memory allocation. This issue is fixed in version 12.3.0. A remote attacker could exploit this vulnerability by providing specially crafted PCF font data. This data, when processed, can lead to excessive memory allocation because the library does not properly check for decompression bombs. The primary consequence is a Denial of Service (DoS), which could make the affected system or application unavailable. Red Hat severity: Important — CVSS 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Weakness: CWE-409. Affected products named by the advisory: Red Hat Ansible Automation Platform 2.5 for RHEL 8; Red Hat Ansible Automation Platform 2.5 for RHEL 9; Red Hat Ansible Automation Platform 2.6 for RHEL 9; Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support; and 11 more.
High [CVE-2026-43825] Remote code execution via untrusted Java deserialization
Untrusted Java Deserialization in Apache OpenNLP SvmDoccatModel Versions Affected: before 3.0.0-M4 (libsvm document categorization module; introduced in OPENNLP-1808 and only present on the 3.x line) Description: SvmDoccatModel.deserialize(InputStream) reads an attacker-controlled stream with java.io.ObjectInputStream and calls readObject() without an ObjectInputFilter installed. ObjectInputStream materialises every class referenced in the stream before the resulting object is cast to SvmDoccatModel, so the cast that follows readObject() executes only after the foreign object graph has already been deserialised in full. If a Java deserialization gadget chain is available on the consumer's classpath, a crafted payload supplied to deserialize() executes arbitrary code in the JVM that loads it. Apache OpenNLP itself does not ship a known gadget chain, so the realistic risk is to downstream applications that embed the libsvm module alongside vulnerable transitive dependencies. The method is public and static, so any caller can pass an untrusted stream to it directly. The practical impact is remote code execution against processes that load SvmDoccatModel instances from untrusted or semi-trusted origins. Mitigation: 3.x users should upgrade to 3.0.0-M4.
High [CVE-2026-59195] Path traversal in configDependencies env lockfile allows symlink creation outside node_modules/.pnpm-config
pnpm is a package manager. A malicious repository can commit a crafted pnpm-lock.yaml whose env-lockfile document contains a traversal-shaped config dependency name. During pnpm install, pnpm installs the config dependency and creates a symlink at a path derived from that name. This vulnerability is fixed in 10.34.4 and 11.8.0. A remote attacker could exploit a path traversal vulnerability by crafting a malicious `pnpm-lock.yaml` file. This allows an attacker to achieve arbitrary file writes within the victim's project directory, potentially extending to other areas of the filesystem. A malicious repository containing a specially crafted `pnpm-lock.yaml` file can lead to the creation of arbitrary symlinks outside the intended `node_modules/.pnpm-config` directory during `pnpm install`. This provides an attacker with a filesystem write primitive, even when `--ignore-scripts` is used, increasing the risk of unauthorized file manipulation. Red Hat severity: Important — CVSS 8.2 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:L). Red Hat lists Red Hat AMQ Broker 7; Red Hat Build of Keycloak; Red Hat JBoss Enterprise Application Platform 8; Red Hat JBoss Enterprise Application Platform Expansion Pack as not affected.
High [CVE-2026-59194] patch-remove could delete project-selected files outside the patches directory
pnpm is a package manager. Prior to 10.34.4 and 11.7.0, a crafted patch entry could resolve outside the configured patches directory and cause pnpm patch-remove to delete an arbitrary reachable file. This vulnerability is fixed in 10.34.4 and 11.7.0. A remote attacker could exploit this vulnerability by providing a specially crafted patch entry. This could lead to data integrity issues or a denial of service. When the `pnpm patch-remove` command processes such an entry, it may resolve paths outside the intended patches directory, allowing the deletion of arbitrary files. While the primary issue is addressed by validating paths, a local attacker could still exploit a time-of-check/time-of-use race condition to achieve similar effects. Red Hat severity: Important — CVSS 7.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L). Weakness: CWE-22. Red Hat lists Red Hat AMQ Broker 7; Red Hat Build of Keycloak; Red Hat JBoss Enterprise Application Platform 8; Red Hat JBoss Enterprise Application Platform Expansion Pack as not affected.
High [CVE-2026-58380] stack buffer overflow in pnmscanner_gettoken
A flaw was found in GIMP's PNM file format parser. When parsing a specially crafted PNM file, the pnmscanner_gettoken() function writes a null terminator one byte past the end of a stack-allocated buffer due to an off-by-one error in the loop boundary check. This could lead to memory corruption, potentially resulting in denial of service or arbitrary code execution. The vulnerability requires a user to open a specially crafted PNM image file with GIMP. As a desktop application, the impact is limited to the user's session and requires user interaction. Red Hat severity: Moderate — CVSS 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H). Weakness: CWE-193. Affected Red Hat products: Red Hat Enterprise Linux 8; Red Hat Enterprise Linux 9; Red Hat Enterprise Linux 6; Red Hat Enterprise Linux 7. Will not fix / out of support: Red Hat Enterprise Linux 6. Red Hat fixing advisory: RHSA-2026:62507, RHSA-2026:40751. Affected products named by the advisory: Red Hat package: gimp.
High [CVE-2026-9165] Unbounded GraphQL query depth allows authenticated denial of service
A flaw was found in Red Hat Advanced Cluster Security for Kubernetes (RHACS). Central does not limit the depth of GraphQL queries served on the authenticated GraphQL API. An authenticated user with a valid API token can send deeply nested queries that cause excessive resource consumption in Central, resulting in a denial of service for the management plane. Red Hat Product Security is aware of this issue affecting RHACS Central. Red Hat is not aware of malicious exploitation of this issue outside of coordinated testing. Updates addressing this issue will be released according to the RHACS support lifecycle. Refer to the associated errata when available for affected versions and update instructions. Red Hat severity: Important — CVSS 7.7 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H). Weakness: CWE-400. Red Hat fixing advisory: RHSA-2026:36319, RHSA-2026:36625, RHSA-2026:36207. Affected products named by the advisory: Red Hat Advanced Cluster Security 4.9; Red Hat Advanced Cluster Security for Kubernetes 4.10; Red Hat Advanced Cluster Security for Kubernetes 4.11.
High [CVE-2026-43866] Apache Camel JMS components: Arbitrary Exchange state injection
Deserialization of Untrusted Data vulnerability in Apache Camel, Apache Camel JMS component. JmsBinding.extractBodyFromJms() in camel-jms - and the equivalent JmsBinding in camel-sjms - deserializes the payload of an incoming JMS ObjectMessage via jakarta.jms. ObjectMessage.getObject() whenever the mapJmsMessage option is enabled (the default) and Camel acts as a JMS consumer. The CVE-2026-40860 hardening added a post-deserialization class check that rejects classes outside the default allow-list java.**;javax.**;org.apache.camel.**;!*. However org.apache.camel.support. DefaultExchangeHolder itself lives in the allow-listed org.apache.camel.** namespace, so an ObjectMessage whose top-level object is a DefaultExchangeHolder passes the check. The receiving side then calls DefaultExchangeHolder.unmarshal() on it without requiring the transferExchange option to be enabled - an asymmetric trust boundary, since the sending side gates ObjectMessage and transferExchange handling but the receiving side did not - writing every non-null field of the holder into the Exchange: the message body, the IN and OUT headers, the exchange properties, the variables, the exchange id and the exception. Affected product named by the advisory: Red Hat build of Apache Camel 4.18.3 for Spring Boot 3.5.16.
High [CVE-2026-46726] Server-Side Request Forgery and sensitive data exposure
Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel in Vertx Websocket component. The camel-vertx-websocket consumer mapped inbound WebSocket query and path parameters into the Camel Exchange header map without applying any HeaderFilterStrategy (VertxWebsocketConsumer.populateExchangeHeaders()). Because nothing blocked the Camel header namespace, a client connecting to the WebSocket endpoint could set Camel-internal control headers - including CamelHttpUri (Exchange.HTTP_URI) - simply by supplying them as query parameters. In a route where the WebSocket consumer feeds a downstream HTTP producer, the injected CamelHttpUri redirects the server-side HTTP request to an attacker-chosen destination (server-side request forgery - for example to an internal service or a cloud metadata endpoint). In addition, the HTTP producer resolves Camel property placeholders on the resulting (attacker-controlled) URI, so placeholders embedded in the injected value - such as an environment-variable reference, an application property, or a vault reference - are resolved to their real values and sent to the attacker, disclosing environment variables, application properties and vault secrets.
High [CVE-2026-46592] Remote attacker can execute unintended operations via header manipulation
Improper Input Validation, Unintended Proxy or Intermediary ('Confused Deputy') vulnerability in Apache Camel CXF SOAP component. The camel-cxf producer selects which SOAP operation to invoke on the backend service from the operationName (and operationNamespace) Exchange header, whose constant values (CxfConstants.OPERATION_NAME / OPERATION_NAMESPACE) were the plain strings operationName / operationNamespace. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a cxf: producer, any HTTP client could therefore set the operationName header and have CxfProducer resolve and invoke a different WSDL operation than the route intended - for example replacing a read operation with a destructive one - against the backend SOAP service (a confused-deputy redirection). The constant is defined in the shared camel-cxf-common module, so the same non-prefixed names also applied to camel-cxfrs. No credentials are required when the bridging consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0.
High [CVE-2026-46584] Credential exposure and information disclosure via improper input validation of mail headers
Improper Input Validation, Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel Mail Component. The camel-mail producer (MailProducer.getSender) scanned the outgoing Exchange for message headers in the mail.smtp. / mail.smtps. namespace and, when any were present, built a per-message JavaMail sender with those values applied as JavaMail session properties, overriding the endpoint configuration. This namespace is Camel-internal - only MailProducer interprets it - and was not blocked by any HeaderFilterStrategy, so the values could originate from any inbound protocol (for example platform-http query parameters or request headers, or JMS / Kafka messages from untrusted producers) that feeds a route ending in an smtp / smtps producer without an intervening removeHeaders. Affected products named by the advisory: Red Hat build of Apache Camel 4.18.3 for Spring Boot 3.5.16; Red Hat build of Apache Camel 4 for Quarkus 3.
High [CVE-2026-40859] Apache Camel (camel-vertx-http): Remote Code Execution via Deserialization of Untrusted Data
Deserialization of Untrusted Data vulnerability in Apache Camel. The camel-vertx-http component deserializes HTTP response bodies carrying the Content-Type application/x-java-serialized-object using a raw java.io.ObjectInputStream, without applying any ObjectInputFilter (VertxHttpHelper.deserializeJavaObjectFromStream) This deserialization path is reached only when the producer endpoint is configured with transferException=true (or the component-level allowJavaSerializedObject=true) and throwExceptionOnFailure is left at its default value of true; in that case a backend HTTP response with a 5xx status and the application/x-java-serialized-object content type has its body deserialized with no class restrictions. An attacker who controls the backend the Camel producer talks to - through a man-in-the-middle position on an unencrypted (plain HTTP) connection, or by compromising the backend service - can return a crafted serialized Java object and, if a suitable gadget chain is present on the classpath, achieve remote code execution on the Camel application host. The path is not reachable in the default configuration, where transferException is false. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.20.0. Users are recommended to upgrade to version 4.20.0, which fixes the issue.
High [CVE-2026-14570] Crypt::DSA: Crypt::DSA: Private key recovery due to biased random number generation
Crypt::DSA versions before 1.22 for Perl draw the DSA signing nonce and private key from a biased random generator, leading to private-key recovery. "Crypt::DSA::Util::makerandom forces the high bit of every value it returns to obtain an exactly N-bit integer for prime search. Because the high bit is always set, the result is not uniform: its top bit is fixed, producing insecure values." An attacker who collects a modest number of signatures under an affected key, together with the public key, can recover the private key with a lattice attack. Keys used to sign with an affected version should be considered compromised and new keys should be generated. The random number generator used for DSA signing nonces and private key generation has a bias (the high bit is always set), allowing an attacker who collects a modest number of signatures to recover the private key via a lattice attack. Red Hat does not ship perl-Crypt-DSA in any supported product. This issue only affects the perl-Crypt-DSA package available in Fedora and EPEL community repositories. Red Hat severity: Important — CVSS 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). Weakness: CWE-338.
High [CVE-2026-14535] Arbitrary code execution via pickle deserialization bypass
In Trail of Bits fickling versions up to and including 0.1.11, the UnsafeImportsML analysis pass unconditionally calls AnalysisContext.shorten_code(node) on every import node it inspects, regardless of whether the import is flagged as unsafe. This call registers the shortened code representation in the shared AnalysisContext.reported_shortened_code set. When the MLAllowlist analysis pass subsequently runs, it calls the same shorten_code() method, receives already_reported=True for every import, and executes a continue statement that skips its allowlist check entirely. This renders MLAllowlist dead code for all imports — it never evaluates whether an import is in the ML allowlist or not. The MLAllowlist pass was designed to catch imports of modules outside the known-safe ML ecosystem (torch, numpy, transformers, etc.) that slip past the UnsafeImports denylist. With MLAllowlist inoperative, any standard library module not in the UNSAFE_IMPORTS denylist can be invoked via pickle deserialization while fickling's check_safety() returns LIKELY_SAFE. The fickling.load() API chains check_safety() into pickle.loads() as an explicit security gate, meaning a LIKELY_SAFE verdict causes the payload to be deserialized and executed. Affected product named by the advisory: Exploit Intelligence.
High [CVE-2026-14534] Arbitrary code execution due to incomplete denylist in deserialization
Trail of Bits fickling versions up to and including 0.1.10 do not include the Python standard library modules _posixsubprocess, site, and atexit in the UNSAFE_IMPORTS denylist (fickle.py). Because these modules are absent from the denylist, fickling's check_safety() function returns LIKELY_SAFE with zero findings for pickle payloads that invoke dangerous functions including _posixsubprocess.fork_exec (C-level process spawner capable of executing arbitrary binaries), site.execsitecustomize (executes arbitrary site customization code), and atexit._run_exitfuncs (triggers all registered exit handler callbacks). The fickling.load() API chains check_safety() into pickle.loads() as an explicit security gate; a LIKELY_SAFE verdict causes the payload to be deserialized and executed. This shares the same root cause as CVE-2026-22607 (cProfile), CVE-2025-67748 (pty), and CVE-2025-67747 (marshal/types). OvertlyBadEvals does not flag these modules because they are standard library imports. UnsafeImports does not flag them because they are not in the denylist. The UnusedVariables heuristic is defeated by the SETITEMS opcode pattern. A flaw was found in the `fickling` library, which is designed to safely handle Python pickle data. Affected products named by the advisory: Exploit Intelligence; Red Hat Hardened Images.
High [CVE-2026-12252] Arbitrary Code Execution via Untrusted JAR File Loading
In nltk/nltk versions 3.9.3 and earlier, five Stanford interface classes (StanfordPOSTagger, StanfordNERTagger, StanfordParser, StanfordDependencyParser, and StanfordNeuralDependencyParser) are vulnerable to untrusted JAR code execution. These classes accept user-controllable JAR paths and execute them via the `java()` function, which invokes `subprocess. Popen()` without integrity verification. This vulnerability is identical to CVE-2026-0848, which was fixed for StanfordSegmenter by adding SHA256 verification. However, the fix was not applied to these additional classes, leaving them susceptible to arbitrary code execution when loading untrusted JAR files. A flaw was found in the `nltk` library. This vulnerability allows a local attacker to execute malicious code by providing an untrusted Java Archive (JAR) file, as the system lacks integrity verification for these files. Red Hat severity: Important — CVSS 7.8 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H). Weakness: CWE-347. Affected Red Hat products: OpenShift Lightspeed. Red Hat does not currently list a fixing RHSA for this CVE.
High [CVE-2026-53362] account for fraggap on the paged allocation path
In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.
High [CVE-2026-53359] Fix shadow paging use-after-free due to unexpected role
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected role Commit 0cb2af2ea66ad ("KVM: x86: Fix shadow paging use-after-free due to unexpected GFN") fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. The rmap_remove() call would miss entries created after the PDE change because the GFN of the leaf SPTE does not match the GFN of the struct kvm_mmu_page. A similar hole however remains if the modified PDE points to a non-leaf page. In this case the gfn can be made to match, but the role does not match: the original large 2MB page creates a kvm_mmu_page with direct=1, while the new 4KB needs a kvm_mmu_page with direct=0. However, kvm_mmu_get_child_sp() does not compare the role, and therefore reuses the page. The next step is installing a leaf (4KB) SPTE on the new path which records an rmap entry under the gfn resolved by the walk. But when that child is zapped its parent kvm_mmu_page has direct=1 and kvm_mmu_page_get_gfn() computes the gfn for the 4KB page as sp->gfn + index instead of using sp->shadowed_translation[] (or sp->gfns[] in older kernels). It therefore fails to remove the recorded entry.
High [CVE-2026-53360] Require in-GHCB scratch area if GHCB v2+ is in use
In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use As per the GHCB spec, when using GHCB v2+ require the software scratch area to reside in the GHCB's shared buffer. Note, things like Page State Change (PSC) requests _rely_ on this behavior, as the guest can't provide a length when making the request, i.e. the size of the guest payload is bounded by the size of the shared buffer. Failure to force usage of the GHCB, and a slew of other flaws, lets a malicious SNP guest corrupt host kernel heap memory, and leak host heap layout information. setup_vmgexit_scratch() allocates a buffer via kvzalloc(exit_info_2), where exit_info_2 is guest-controlled. With exit_info_2=24, this yields a 24-byte allocation in kmalloc-cg-32 (32-byte slab objects). The buffer holds an 8-byte psc_hdr followed by 8-byte psc_entry structs, so only entries[0] and entries[1] are in-bounds. snp_begin_psc() validates end_entry against VMGEXIT_PSC_MAX_COUNT (253) but NOT against the actual buffer size: idx_end = hdr->end_entry; if (idx_end >= VMGEXIT_PSC_MAX_COUNT) { // checks 253, not buffer snp_complete_psc(svm,...); return 1; } for (idx = idx_start; idx = 2 The guest sets end_entry=10+, causing the host to iterate entries[2+] which are OOB into adjacent slab objects.
High [CVE-2026-53361] Set gc_in_progress to true in unix_gc
In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' |... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. A race condition exists within the `unix_gc()` garbage collection function where the `gc_in_progress` flag may not be correctly set. This could lead to `unix_peek_fpl()` misinterpreting garbage collection status when handling `MSG_PEEK` operations, potentially causing unexpected behavior or information disclosure to a local attacker. Red Hat severity: Important — CVSS 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-366. Affected Red Hat products: Red Hat Enterprise Linux 10; Red Hat Enterprise Linux 10.0 Extended Update Support. Affected products named by the advisory: Red Hat package: kernel.
High [CVE-2026-12481] Arbitrary code execution via deserialization vulnerability
A vulnerability in keras-team/keras version 3.14.0 allows for arbitrary code execution due to improper handling of deserialization in the `Lambda` layer. Specifically, the `_raise_for_lambda_deserialization()` function fails to enforce the safe-mode guard when `safe_mode` is set to `None`, which is the default value when `from_config()` is called outside of a `SafeModeScope` context. This logic error conflates `None` (unset/default-deny) with `False` (explicitly disabled), bypassing the guard and allowing attacker-controlled `marshal` bytecode to be deserialized. Affected call sites include `keras.layers.deserialize(config)`, `keras.models.clone_model(model)`, and any direct invocation of `Lambda.from_config(config)` without an enclosing `SafeModeScope(True)`. This vulnerability can be exploited to achieve arbitrary OS-level code execution in the context of the server or user process. A flaw was found in the Keras deep learning library. Specifically, a security safeguard designed to prevent unsafe deserialization is bypassed when the `safe_mode` setting is not explicitly enabled, allowing malicious code to be processed. This can lead to complete compromise of the affected server or user process. Exploitation requires user interaction, such as loading a specially crafted Keras model. Red Hat severity: Important — CVSS 8.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H).