CISA flags exploited Openwave webmail attachment flaw
News
Published 10 Nov 2026
Updated 10 Nov 2026
7 min read
Summarize with
CISA added CVE-2026-111793, an actively exploited flaw in Openwave Webtop Media Transcoder, to its Known Exploited Vulnerabilities (KEV) catalog on November 10, 2026 (UTC). The component supports webmail attachment previews and conversion. The November listing follows the developer's report of observed attacks. See the CISA KEV catalog.
Japan Vulnerability Notes (JVN), run by JPCERT/CC and Japan's Information-technology Promotion Agency (IPA), reported on November 9 that Openwave had seen attacks exploiting the flaw. Versions before 1.1.22.0 are affected. Exploitation requires authenticated access, and JVN describes possible exposure of sensitive information. See the official JVN advisory.
What changed in November
Openwave's security advisory and the CVE were already public in October. A fixed build was already available. The new information is that Openwave has observed exploitation and CISA has added the flaw to KEV. If you assessed the CVE in October and deferred an update, reopen that decision using the latest deployment inventory.
The November 24, 2026 remediation deadline in the KEV entry applies only to covered U.S. federal civilian agencies. For hosting operators and other organizations running Webtop, observed exploitation is the reason to prioritize remediation. Set the change window based on your exposure and how quickly you can roll out and verify the supported update.
A KEV entry gives vulnerability management teams a concrete reason to move an existing ticket forward. For this issue, find the record under CVE-2026-111793 and check which service owners have already confirmed their status. A prior assessment can still help if it names the actual component and records the build that was running at the time.
|
|
|---|---|
October 2026 | Vendor advisory and CVE published |
November 9 | JVN reports observed exploitation |
November 10 | CISA adds the flaw to KEV |
November 24 | Covered federal agency deadline |
Which installations need attention
Use the version of Webtop Media Transcoder that actually handles previews and conversions. A version shown in the webmail interface can describe a different part of the deployment. Ask the team that owns the service to confirm the installed and running transcoder build, along with which Webtop environments use it.
Start with instances reachable through webmail services that users sign in to from the internet. Include every transcoder instance those services can use, including shared backends and standby nodes that can take traffic after failover. An old backend can remain in use after the visible webmail tier has been updated.
Use deployment records alongside the live inventory. Include internal Webtop services in the version check, and record which user populations can sign in to each service. If the component or version is unknown, assign someone to confirm it. In a hosted environment, ask for an answer that covers your tenant or service region.
If you run Webtop
Map each deployment to its transcoder instances. Record the running build and whether each instance handles traffic now or can receive traffic during failover. Assign someone to verify each instance after the change.
If a provider runs Webtop
Ask the provider whether your service uses the affected component and whether it was running an affected build. Request confirmation of the deployed fix, when it took effect, and how the provider will handle any findings relevant to your service.
How to apply and verify the fix
Openwave identifies 1.1.22.0 as the first fixed build. Its remediation guidance directs customers to the latest supported Media Server 2.0 release. Confirm the supported upgrade path for your deployment with Openwave, particularly if you run a legacy branch or have a managed installation. See the vendor remediation advisory.
We treat the running build and the attachment preview as two separate checks. The first tells you whether the fixed software is handling requests. The second tells you whether users can still preview and convert attachments through their usual workflow. Capture both in the change record.
If the deployment lacks a supported upgrade path, ask Openwave which mitigations it supports. The KEV entry calls for discontinuing use when mitigations are unavailable. Coordinate that decision with the service owner so they can account for users who depend on attachment previews and conversion.
- Confirm the baseline. Record the running build, the instances that can serve requests, and the expected attachment preview and conversion behavior for your deployment.
- Apply the supported update. Follow the vendor's instructions for the upgrade and any required service restart. In a clustered deployment, account for each node that handles previews, including nodes brought back into rotation after maintenance.
- Verify each running build. Check the active component on each instance after rollout. If you use a shared image or package, confirm that the instances are actually running it and that standby capacity uses the updated build.
- Test a routine preview. Use a standard test account and a benign attachment supported by your deployment. Verify that the preview renders and that routine conversion works where enabled. Record the test time and result with the version evidence.
For a staged rollout, verify the updated instance before widening the change. Watch for errors in ordinary preview and conversion requests after each batch, and check that the next batch uses the same approved package. When the rollout is complete, compare the final instance list with the initial inventory to catch hosts that were offline during maintenance.
If a node fails validation, keep the remediation ticket open and document whether that node can still handle traffic. If the service needs a rollback, confirm whether the rollback restores an affected build and agree on the vendor-supported next step before returning the instance to service.
What to check in logs
Ask incident response which records are available for the period when the affected build was in service. Start with webmail authentication logs, relevant access logs, and transcoder service logs where available. Record the affected instances and the time zone used by each log source so responders can correlate activity across systems.
The November 9 advisory gives operators a disclosure date. Use your deployment history and log retention to establish the window for review. Prioritize preserving records that would otherwise rotate out during the upgrade, and note any periods or instances with missing coverage.
Escalate suspicious activity
If the review turns up suspicious activity, preserve the relevant records and bring in incident response. Share the affected build, the instances involved, the patch timeline, and the available log coverage. Responders can use that evidence to assess whether exploitation occurred and what information was at risk.
For an initial review, compare the timestamps of suspicious application activity with the corresponding sign-ins and maintenance events. Treat unexpected errors or unusual access patterns as leads for correlation with other records. If you rely on hosted webmail, ask the provider to preserve relevant records and tell you what it can verify for your service.
Keep a record of which logs the team reviewed and what time range they cover. A confirmed patch closes the software exposure going forward. The log review helps establish what took place while the older build was running.
Where SPF, DKIM and DMARC fit
This CVE affects software that processes attachments after a user signs in to webmail. SPF checks sending server authorization for the envelope sender domain. DKIM verifies a signature tied to a signing domain. DMARC checks whether a passing SPF or DKIM domain matches the visible From domain under the domain owner's policy.
Those checks authenticate sender domains. The vendor update fixes the transcoder. If your mail team also needs to check how a message from an approved sender authenticates, send a separate test message and inspect the results in our Suped Email Tester.
For ongoing sender authentication, our Suped platform can group DMARC aggregate reports by sending source so you can investigate failures in DMARC monitoring. For this CVE, use the running component version and the attachment preview test as evidence of remediation.
Close the remediation with evidence
Record the fixed build and rollout time for every instance that can handle previews. Attach the normal preview test result and name the owner of any outstanding log review. If a provider operates the service, attach its confirmation for your environment so the remediation record identifies the deployment it covers.
Give support staff the change window and the expected preview behavior so they can route any post-upgrade issues to the right owner. If there are deployments awaiting a vendor decision, keep them visible in the same inventory with a named owner and a date for follow-up.
Frequently asked questions
It is a vulnerability in Openwave Webtop Media Transcoder, the component that supports webmail attachment previews and conversion. JVN reports that exploitation requires authenticated access and can expose sensitive information.
Versions earlier than 1.1.22.0 are affected. Openwave identifies 1.1.22.0 as the first fixed build and directs customers to the latest supported Media Server 2.0 release for remediation.
CISA's November 24, 2026 deadline applies to covered U.S. federal civilian agencies. Private operators should prioritize their own remediation schedule based on the reported exploitation and their deployment's exposure.
Verify that every instance that can handle attachment previews is still running the fixed build, including standby instances. Check the recorded rollout date against the period your team needs to review for suspicious activity.
