Android CVE-2026-58882 ("SMS of Death"): what Lithium can do, and how to block WAP Push SMS with the FAF

Overview

Does the Android vulnerability CVE-2026-58882, also called "SMS of Death", affect NewNet Lithium? Does Lithium relay WAP Push SMS, can it detect the malformed message, and can it block WAP Push on the SMSC firewall (FAF) or the RTR?

CVE-2026-58882 is a defect in Android handsets, not in Lithium. Lithium servers are not affected. Lithium cannot detect the malformed message. It can block WAP Push SMS as a class with the FAF "Ems Condition". This article gives the facts, the recommended policy and the procedure.

Information

The vulnerability

The Android Security Bulletin of November 2026 lists CVE-2026-58882 in the System component, type denial of service, severity Critical. The fix is in security patch level 2026-11-01 and later, for Android 14, 15, 16 and 17. Public reports describe the attack as a malformed WAP Push SMS sent to the handset's WAP Push port, 2948. The malformed data is in the WAP Push payload, after the user data header (UDH).

The real fix is the handset update to security patch level 2026-11-01 or later. A network-side block reduces the exposure of handsets that are not updated. It does not remove it.

What Lithium can and cannot do

Question	Answer
Does Lithium relay WAP Push (UDH, DCS, binary payload) unchanged?	Yes, by default. Nothing stops WAP Push unless you configure a filter.
Can Lithium match WAP Push by destination port 2948?	Yes. The FAF Ems Condition reads the 16-bit port-addressing element (IEI 05) in the UDH and compares the destination port. This needs the licensed "EMS Module".
Can Lithium tell a malformed WAP Push from a valid one?	No. Neither the RTR nor the FAF decodes the WAP payload. The RTR checks the SMS structure only: user data length, header length and element lengths. A correctly framed malformed WAP Push passes those checks.
Can Lithium match the binary payload content?	No. For 8-bit binary user data, routing conditions can check the length only.
Which traffic paths can the filter see?	MO messages from your subscribers and AO messages from applications always pass the RTR rule sets. Inbound MT messages from other networks are inspected only when they are home-routed through the RTR, that is, when the RTR handles the SRI-SM. MT messages that reach your MSC without the RTR are not inspected.
Does a port-2948 block affect legitimate traffic?	Yes. MMS notifications and OMA device-management (OTA) messages also use WAP Push on port 2948. The filter must let your own MMSC and OTA originators pass.

Recommended policy

In line with the GSMA Binary SMS Filtering Guidelines (FS.42):

• Block WAP Push to port 2948 from person-to-person sources: your own subscribers (MO) and home-routed inbound MT from other networks.
• Allow WAP Push to port 2948 from applications (AO) only for approved originators: your MMSC, your OTA or device-management platform, and named business services. Block it from all other applications.

Why not filter on DCS or PID

WAP Push messages are 8-bit binary SMS. Commonly seen values are DCS F5 (8-bit data, message class 1) or DCS 04 (8-bit data), with PID 00. Do not use these values as the filter criterion:

• The sender controls both values and can change them.
• Legitimate binary SMS (MMS notifications, OTA settings, application data) uses the same values.

The reliable criterion is the port-addressing element in the UDH: IEI 05 with destination port 2948. The Ems Condition matches exactly that. Use DCS or PID only as an extra condition on the same rule, never alone.

Who does what

Your team configures the change in your MGR. Contact NewNet Support if you have questions about this procedure.

Solution

Before you start

1. FAF licence. On each FAF node, run tp_system --tp_faf <FAF host>. In the output, the line for EMS Module must show enabled (the spacing between the words can vary). If a node shows disabled, contact your Account Manager for the licence before you continue.
2. Approved application originators. List the short codes, alphanumeric senders and ESME accounts that send WAP Push legitimately: your MMSC, your OTA or device-management platform, and each business service. Without this list, the application rule also blocks MMS notifications.
3. Sites and paths. For each SMSC site, decide which paths you protect: MOX (your subscribers), MTIX (home-routed inbound MT) and AOX (applications). Check whether inbound MT is home-routed at that site. If it is not, the MTIX rule gives no protection there. Record this in your change plan.
4. Existing filters and rules. Record the existing FAF filters and their priorities (Advanced Filters > Filters) and the existing external condition rules (MOX, MTIX and AOX tables). The FAF stops at the first filter that matches. An existing rule may already send the traffic to the FAF. Then you need only a new filter, not a new rule.
5. Maintenance window. You can change "Inc. User Data Header" on the FAF EC application entry only while that entry is inactive. If it is not checked yet, plan a short window for each site.
6. Backup. Back up the MGR configuration before the change.

Procedure

Do the steps in this order. The order prevents an accidental block of all traffic.

1. Check the licence on every FAF node ("Before you start", item 1).
2. Configure the EC application entry that feeds the FAF. In the MGR, open Routing > EC Applications > Applications. If Inc. User Data Header is unchecked, deactivate the entry, check the field, and activate the entry again. Keep Inc. Protocol Id unchecked for this filter. If another filter needs it checked, you must fill the Protocol Id Values field in step 4 (see "Cautions", item 2).
3. Create the filter. Open Advanced Filters > Filters. Create a filter with Action = Return True. Give it a name: the FAF returns the filter name to the RTR, and the Log Viewer shows it only if the name is not empty. Give the filter a higher priority than any other filter that returns a result for the same messages.
4. Add the condition. Add an Ems Condition to the filter: - In Fields, select 05 - Application port addressing scheme, 16 bit address. - In 16 Bit Destination Port, enter 2948. - Leave 16 Bit Source Port empty. If you set both ports, both must match, and the sender chooses the source port. - Leave Protocol Id Values empty. - Activate the condition.
5. Add or adapt the external condition rule on each protected path. Set EC Application = the FAF entry from step 2: - MOX (messages your subscribers send): Failure Action = Discard with acknowledgment. The sender gets a normal acknowledgment and the RTR drops the message. - MTIX (home-routed inbound MT): Failure Action = Discard with permanent error. A permanent error tells the sending SMSC not to try again. A temporary error makes the sending SMSC try again. - AOX (messages from applications): apply the rule to all originators except the approved list ("Before you start", item 2). Set Failure Action = Discard with negative acknowledgement, so that the application sees the rejection. As an alternative, put an allow rule for the approved originators at a higher priority.
6. Observe before you block. Keep the filter on Return True for at least one normal traffic day. The Log Viewer shows the filter name on each matching message. Make sure that only WAP Push from untrusted sources matches, and that no MMS notification or OTA message from your approved platforms matches.
7. Switch the filter to Return False. Open the filter from step 3 and set Action = Return False. From this moment, the RTR applies the Failure Action from step 5 to each matching message. To roll back, set the filter back to Return True.

Cautions

1. A filter with Action = Return False and no active condition blocks every message that is routed to it. Create the filter with Return True first (step 3). Switch to Return False last (step 7). See also SMSC Discarding All SMS.
2. An empty Protocol Id Values field matches any protocol id. The Ems Condition combines its UDH test and its protocol id test with OR. If the EC application sends the protocol id (Inc. Protocol Id checked) and the Protocol Id Values field is empty, the condition matches every message, including plain text. Keep Inc. Protocol Id unchecked for this filter, or fill the Protocol Id Values field.
3. A port-2948 block also blocks MMS notifications and OTA device-management messages. Exclude the originators of that traffic (step 5).
4. The filter sees home-routed MT only. MT messages that reach your MSC without the RTR in the SRI-SM path are not inspected.
5. The filter does not inspect the payload. It blocks all WAP Push to port 2948 from the selected sources, valid or malformed.

Alternative: RTR routing rule (coarse)

The MO, MTI and MTO routing rules have a condition User Data Hdr [cond]. Set it to 05 to match every message that uses 16-bit port addressing. This option needs no FAF and no EMS licence. It cannot check the port number, so it blocks every port-addressed message, not only WAP Push. On the MT-MT path, the RTR does not evaluate this condition at the SRI-SM stage, because the user data is not known at that point.

Versions

The Ems Condition port fields (16 Bit Source Port, 16 Bit Destination Port) are available in FAF R02.03.00.00 and later. The menu names in this article come from the MGR in Release 22.x. Older MGR versions use the same table and field names, but the menu position can be different.

Testing

1. On each protected person-to-person path, send a WAP Push test message to port 2948 from a test handset or an SMS test tool that can send port-addressed binary SMS. The message is not delivered, and the Log Viewer shows the filter name. If the message is delivered, check first that Inc. User Data Header is checked on the FAF EC application entry (procedure step 2). Without it, the FAF does not receive the UDH and the condition never matches.
2. From a test application that is not on the approved list, send a WAP Push test message. The application gets a negative acknowledgment.
3. Send an MMS to a test handset. The MMS notification arrives. If it does not arrive, your MMSC originator is not excluded (step 5).
4. From your approved OTA or device-management platform, send a test message. It arrives.
5. If a check fails, set the filter back to Return True (procedure step 7) and contact NewNet Support. Send the following in one message: - The component versions (RTR, FAF, MGR) for each site — from your release inventory. If you cannot get them, give the release name (for example 22.12). - The tp_system --tp_faf <FAF host> output for each FAF node — run the command on each node. If you cannot run it, say which nodes you could not check. - The FAF EC application entry settings: Inc. User Data Header, Inc. Protocol Id, and the default responses — from Routing > EC Applications > Applications (a screenshot is enough). - The filter, the Ems Condition and the external condition rules you created, with their priorities and Failure Actions — screenshots or an export of the MGR tables. - The results of checks 1 to 4, each with the test MSISDN or ESME account and the time in UTC. - Log Viewer samples for a blocked message and for a message that was delivered but should have been blocked (or the reverse). If you cannot export them, give the message time in UTC and the originator.

Related

• Android Security Bulletin, November 2026: https://source.android.com/docs/security/bulletin/2026/2026-11-01
• GSMA FS.42 "Binary SMS Filtering Guidelines" and GSMA SG.22 "SMS Firewall Best Practices and Policies".
• SMSC Discarding All SMS (safe filter rollout).
• FAF Operator Manual, section "EMS condition".