Five security records published in the latest 24-hour window connected an AI model-loading flaw with weaknesses in WordPress administration, customer billing data and payment-linked identity. The common operational problem was timing: several fixes existed before the public CVE records arrived. A team that treats an advisory feed as its first signal can therefore remain exposed even when a safe release is already available.
This brief covers material published between 1 August 2026 at 09:04 Iran time and 2 August 2026 at 09:04 Iran time (05:34 UTC to 05:34 UTC). It distinguishes the disclosure date from the earlier code change or release date.
- A Keras record published 18 minutes before the window closed described local-file disclosure through malicious HDF5 links.
- Two WordPress plugin notices described routes to administrator access in an AI framework and a social-login product.
- Two payment-plugin notices covered customer billing disclosure and a configuration-dependent privilege escalation.
- None of the cited notices said the flaws were being exploited in the wild; CVSS scores describe technical severity, not observed incident frequency.
Keras files could reach beyond the model boundary
The CVE-2026-9335 record published on 2 August says Keras versions through 3.14.0 can automatically follow HDF5 ExternalLinks in KerasFileEditor and keras.saving.load_weights. A malicious .h5, .weights.h5 or .keras file can point to another HDF5 file readable by the victim process. The result is confidentiality loss: model weights or other local HDF5 content may be pulled into the loading workflow.
This is not a claim that opening any Keras file leaks arbitrary operating-system files. The target must be an HDF5 file, the process must be able to read it, and a user or automated workflow must accept the crafted model or weights file. Those limits reduce the attack surface, but shared training infrastructure, model registries and automated evaluation pipelines can satisfy exactly those conditions.
The timing is instructive. Keras's fix commit is dated 20 May, more than two months before the CVE publication. The patch rejects ExternalLink and SoftLink groups before dereferencing them and adds regression tests. The NVD record marks versions through 3.14.0 as affected; Keras released 3.15.0 on 24 June and 3.15.1 on 29 July. Operators should verify the version actually imported by each runtime rather than assuming a newly built image inherited the safer dependency.
Two identity paths reached administrator access
Wordfence, acting as the CVE Numbering Authority, published CVE-2026-15988 on 1 August for the unrelated AI Engine – The Chatbot, AI Framework & MCP for WordPress plugin through version 3.6.5. The record describes missing nonce validation in an OAuth reauthentication function. If an administrator is induced to follow a crafted link, WordPress's method-override behaviour can turn the request into an authenticated REST call that creates a new administrator account. Wordfence assigned a CVSS 3.1 score of 8.8; user interaction is required.
The upstream 3.6.6 version commit is dated 30 July, outside this brief's window but before the public CVE record. That sequence reinforces the need to monitor supplier releases as well as advisory feeds. Sites on 3.6.5 or earlier should move to a current fixed release, inspect administrator creation and OAuth-related activity, and revoke sessions or credentials if evidence suggests compromise.
A second notice, CVE-2026-8457 published on 2 August, concerns the commercial WooCommerce – Social Login plugin through 2.8.7. Its Apple handler allegedly decoded the id_token payload without verifying Apple's signature or validating issuer, audience and expiry. Because the handler resolved the email directly to a WordPress user, a forged token could produce a session for an existing account, including an administrator. Wordfence scored it 9.8 and listed no user interaction or prior account requirement.
The public record did not identify a fixed version. That absence matters. Operators should not infer that an unverified version number is safe: they need a vendor-confirmed release, or should disable the affected Apple login path or plugin until one is installed and tested. The report also gives no evidence of active exploitation, so response priority should combine the technical route with actual deployment and logging evidence.
Payment plugins exposed data and role controls
The two other Wordfence records affect payment-adjacent WordPress workflows, but their conditions and impact differ.
| Notice | Affected versions and condition | Reported consequence | Evidence-based response |
|---|---|---|---|
| CVE-2025-14073, published 1 August | WooCommerce PayPal Payments through 3.3.2; no account required | An insecure direct-object reference could expose an order key, then billing name, email, phone and address through the Store API during a ten-minute post-creation grace period | Upgrade beyond 3.3.2, review order-received and Store API access, and assess whether exposed data requires notification |
| CVE-2026-16635, published 1 August | Pronamic Pay through 10.1.0; requires a Gravity Forms payment feed with Update User Role enabled and mapped to a field, plus a subscriber account | A submitted role value could reach WP_User::set_role without an allowlist or capability comparison, allowing escalation to administrator | Upgrade beyond 10.1.0, identify feeds using the option, compare role changes with form submissions, and remove unexpected administrators |
The PayPal Payments case also shows how far disclosure timing can drift from remediation. Its official 3.4.0 release commit is dated 10 February, almost six months before the CVE record. A merchant could have been protected through ordinary maintenance long before receiving a public identifier. Conversely, an organisation waiting for a CVE-specific change ticket may have retained an old branch for months.
Pronamic Pay's condition should be preserved in triage. A site without the mapped update-role feed does not meet the disclosed exploitation precondition. A site that does meet it should treat the combination of user-controlled form data, payments and role mutation as high consequence. Wordfence scored the issue 8.8, but deployment configuration determines whether that path exists.
The advisory date is not the exposure date
These records were newly published in this brief's window; most underlying code changes were not. That distinction changes both editorial meaning and incident response.
For each dependency, retain four timestamps:
- when the vulnerable behaviour entered the code or configuration;
- when a corrective commit or release became available;
- when maintainers or a CNA made the weakness public; and
- when each production environment actually installed and verified the fix.
The interval between the first and fourth dates is the organisation's likely exposure period. The interval between the second and fourth is avoidable remediation delay. A CVE publication date is useful evidence, but it cannot reconstruct either interval by itself.
This is especially important for AI pipelines. Model artefacts often move through registries, notebooks, object stores and evaluation queues with less scrutiny than application executables. A file that contains no Python code can still instruct a parser to follow an external reference. Our AI cyber-resilience guide explains how to connect dependency signals with observed runtime and identity evidence instead of declaring an incident from a score alone.
Inventory must include reachable features
A package version without feature context is not enough for these notices. The vulnerable path may depend on whether a loader accepts external files, an OAuth or Apple login route is enabled, or a Gravity Forms feed can update roles.
A useful exposure query should answer:
- which runtime imports Keras 3.14.0 or earlier and accepts third-party model files;
- which WordPress sites run the named plugins and their exact versions;
- whether affected OAuth, Apple login, Store API or role-update features are reachable;
- which identities can trigger each path and what permissions the process holds;
- when the safe release reached production, preview and dormant disaster-recovery images;
- whether logs cover account creation, role changes, token failures and sensitive API reads; and
- who owns containment when the plugin is commercial or the fixed version is unclear.
That inventory turns a global advisory into a bounded operational decision. It also prevents the opposite errors of ignoring a medium score that exposes real customer data or treating a conditional high score as proof that every installation was compromised.
Verify remediation with behaviour, not a version label
Installing a release is an input to remediation, not its completion. Confirm that the deployed process uses the expected code, the vulnerable feature is no longer reachable, and relevant evidence remains available.
For the Keras case, test an isolated malicious fixture and confirm that ExternalLink and SoftLink groups are rejected without contacting or reading the target file. Do not run an unknown public proof of concept in production. For WordPress, inventory administrators and recent role changes, exercise login and payment flows in a safe environment, and verify that caches, workers and replicas all run the intended plugin version.
An AI model change-control process is useful here even though the change is security-led: pin the complete release, test expected and hostile artefacts, canary where practical, and retain a rollback that does not restore the vulnerable dependency. A scanner result can close only after runtime verification and exposure review agree.
What to watch next
Three uncertainties remain. First, the cited records do not report exploitation in the wild; that could change as technical details circulate. Second, the Social Login notice does not name a fixed release, so vendor confirmation is the decisive next signal. Third, NVD entries may gain additional platform mappings, analysis or references after their initial publication.
Teams should watch the vendors' release channels, Wordfence records, NVD modification history and their own identity and access logs. The broader lesson is not to predict exploitation from five notices. It is to shorten the time between a supplier's safe release and verified production adoption, while keeping enough feature and runtime evidence to know whether an older deployment was actually reachable.
Yesterday's disclosures arrived late relative to several fixes. Operators do not need to wait for the next identifier to improve: version-aware inventory, feature-level exposure mapping and behavioural verification can turn ordinary dependency maintenance into a measurable security control.
