Link Helpdesks on SR2® Cloud Status

[Resolved] Emergency patching for CVE-2026-48063 affecting WhatsApp channels

Fri, 22 May 2026 08:00:00 +0000

We have performed emergency patching to address a vulnerability, CVE-2026-48063, discovered in an open source component we use to provide WhatsApp functionality. As a result of this it may be necessary to relink your WhatsApp channel if you self-manage your handset. If we fully manage your instance, no action is required as we will test and relink the channel for you.

Due to the critical nature of this issue we have not been able to do this within a pre-scheduled maintenance window.

Instructions for relinking the channel can be found in our online documentation.

As always, if you have any concerns please contact our helpdesk.

WhatsApp Malicious Messages

Fri, 01 May 2026 09:00:00 +0000

A WhatsApp security advisory announced a discovered vulnerability, tracked as CVE-2026-23866, arises from incomplete validation of AI rich response messages that contain Instagram Reels references within WhatsApp.

This vulnerability allows a malicious user to craft a message that triggers the victim’s device to fetch and process media content from an external URL. In some cases, the media content may invoke OS‑controlled custom URL scheme handlers, potentially executing arbitrary code or launching unintended applications. The CVSS score of 4.3 indicates moderate impact and a non‑zero but limited likelihood of exploitation.

We have confirmed via MDM that all Android handsets operated by SR2 Communications have since upgraded to unaffected versions.

If you self-manage your handset for your Link helpdesk’s WhatsApp channel it is your responsibility to follow vendor security advisories and ensure that the handset operating system and applications are secured and regularly patched.

As always, if you have any concerns please contact our helpdesk.

[Resolved] copy.fail (CVE-2026-31431)

Wed, 29 Apr 2026 09:00:00 +0000

We were made aware of CVE-2026-31431 on the afternoon of the 29th April via our threat intelligence feeds and later via a CERT-EU advisory. This affected our systems running Rocky Linux 9 as well as our legacy systems running Debian 13. Patches were not immediately available however migrations could be applied.

Rocky Linux 9

Most of our core systems, including those supporting internal infrastructure and single-sign on, are running Rocky Linux 9. This is based on Red Hat Enterprise Linux 9. Unfortunately, the kernel does not have the algif_aead subsystem compiled as a module and our only option was to prevent the code from initialising via adding kernel arguments at boot time and subsequently rebooting.

grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
reboot

Our Prometheus-based monitoring was able to verify all services returning after reboots.

Debian 13

Some Link Secure Digital Helpdesks hosted on behalf of the Centre for Digital Resilience use our legacy deployment model. For these systems we were able to remove the offending module without requiring a reboot:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null

Verification

To ensure that the mitigation was applied across all hosts, we use Ansible:

    - name: Verify CVE-2026-31431 mitigation
      ansible.builtin.command: "lsmod | grep -E '^{{ item }}\\s'"
      loop:
        - algif_aead # copy fail
      register: module_check
      failed_when: module_check.rc != 1
      changed_when: false
      check_mode: false

We do not run any systems where unrelated users have shell access to the host, meaning that this could only have been used as part of a chain of vulnerabilities first involving obtaining remote code execution as a user. For this reason we do not believe any exploitation was possible in our systems.

Further, an analysis of the protections offered by Podman published shortly after by Gabriel Garrido details how our new deployment architecture would further have limited the “blast radius” of this kind of vulnerability should an exploitation have been possible.

In light of this, we will be prioritising a move of the remaining Link helpdesks using the legacy model to our new Rocky Linux 9 model.

As always, if you have any concerns please contact our helpdesk.

WhatsApp Message Send Issue

Wed, 25 Mar 2026 03:00:00 +0000

Resolved: This issue appears to only affect cases where no conversation history exists with the contact the message is sent to. Due to the nature of the helpdesk, messages are only sent to users that have already sent a message to the helpdesk, so we do not believe this issue will affect our users. We encourage you to get in touch if you do see any issues with your WhatsApp channel however we are no longer monitoring this situation closely. (16:15 UTC — Mar 31)

Monitoring: We are not aware of this issue affecting any helpdesk currently however we continue to monitor. A fix has been found by the upstream project and will be rolled out once released formally. (15:00 UTC — Mar 27)

Monitoring: We have been made aware of an issue with the WhatsApp integration that we use where for some accounts, mostly accounts that have been banned and subsequently unbanned, users are noticing errors on message send. A fix is being investigated by the integration developer. Technical details can be followed on GitHub at https://github.com/WhiskeySockets/Baileys/issues/2441. (03:00 UTC — Mar 25)

WhatsApp introducing usernames

Mon, 01 Dec 2025 12:00:00 +0000

Update - We have deployed updates to the WhatsApp channel and currently do not expect that there will be issues sending and receiving messages.

– 2026-03-17

Investigating - We’re aware that WhatsApp have begun rolling out a new feature replacing phone numbers with usernames. We are monitoring this rollout and making updates to our integration as it evolves, but we expect there to be minor disruptions to service until the roll out is complete.

– 2025-12-01