The Pexip Problem

One of the most interesting things about Pexip Infinity is that a meeting can connect to systems that aren’t people sitting in front of webcams.

A recording service can join as a connection of its own. Pexip can send a dedicated audio and video stream to an external recording or broadcasting service. The recording destination can be separate from the computers participating in the meeting. Pexip documents streaming indicators and participant list entries, so this is not inherently invisible recording.

People in the same meeting can also receive different views. In Virtual Auditorium mode, guests typically see the hosts and can hear other guests without seeing their video. Hosts can have a different layout. The video tiles on your screen are not necessarily a complete visual representation of everyone participating.

An organization can build its own meeting interface around Pexip. This goes beyond changing a logo. Developers can build custom browser clients, and the webpage can be hosted on a different server from the conferencing system handling the connection. You might recognize the website you visited without recognizing the technology underneath it.

Even the decisions about how a call connects can come from another system. Pexip can consult a separate policy server for meeting settings and routing instructions, including which conferencing location should handle the audio and video. The webpage you see, the server directing the connection, and the equipment processing the sound can be separate parts of the same meeting.

That raises a legitimate security question: could this become part of an attacker’s command and control setup?

Potentially, if the attacker controlled the policy server or deliberately deployed the infrastructure. Pexip’s conferencing nodes consult that server for instructions, so control over its responses could influence meeting configuration, participant properties, and where media is handled. The architectural possibility comes from that relationship: the conferencing system relies on decisions supplied by another system.

Those instructions govern the conferencing infrastructure. They do not automatically control a participant’s laptop or override microphone permissions. In a larger attack, the policy server could help coordinate conferencing activity while another component controls the compromised device.

An established MITRE ATT&CK technique relevant to this thinking is T1102.002, Web Service: Bidirectional Communication. It describes attackers using legitimate services to exchange instructions and results with compromised devices.

Whether that qualifies as command and control depends on whether it actually directs compromised systems. A server handling call routing or receiving captured audio has a different role. This is a possible abuse scenario inferred from Pexip’s documented architecture, not a confirmed Pexip attack.

There are, however, documented vulnerabilities affecting the infrastructure itself.

Pexip’s security bulletins describe CVE-2026-103110, which allows a remote attacker to execute code as an unprivileged user on a vulnerable Pexip Infinity conferencing node. In plain English, an attacker could get their code running on a server that handles conferencing.

A separate vulnerability, CVE-2026-103106, allows an attacker who can already run code on a node to escalate to root, the highest level of system privilege. That is a different level of control from simply participating in a meeting.

Then there is CVE-2026-103105. An attacker who already has code execution on one node could exploit an internal API to execute code as an unprivileged user on another node within the Pexip installation. The security concern extends beyond a single compromised server to other parts of the deployment.

Pexip issued fixes for these vulnerabilities. Its bulletin lists corrected releases as 38.2, 39.2, 40.1, and 41.0. These disclosures establish specific technical weaknesses. They do not establish that someone combined them in an attack or used them for surveillance.

Pexip also discusses eavesdropping directly in its own security guidance. Among its recommendations is disabling automatic answering on room systems. That matters because whether a conferencing endpoint answers an incoming call automatically is part of protecting the space around it.

The same guidance discusses rogue calls and malicious signaling or media packets. Specially crafted traffic can exploit vulnerabilities in conferencing software or equipment, potentially causing crashes or unauthorized code execution. Pexip describes these as threats organizations need to defend against, rather than reporting that a particular customer was attacked.

I did not find a credible public report establishing that Pexip Infinity was used in a warrantless surveillance operation, an espionage campaign, or an attacker command and control setup. What is documented is the architecture, the vulnerabilities, and the vendor’s recognition of eavesdropping and conferencing attack risks.

Together, those give us concrete reasons to examine how this infrastructure is configured, who controls it, and whether it is patched.

What looks like a video meeting can involve a separate recording destination, different participant views, a custom website, an external policy server, and equipment located somewhere else.

Understanding what is on your screen is only part of understanding where the audio and video actually go.

Since the original article compilation, I have found that there were actually ten CVEs published on September 30, 2026. The others included vulnerabilities involving media processing, signaling media processing, and denial of service attacks. A platform designed to connect people and systems could, if compromised, provide an attacker with infrastructure for connecting compromised systems as well.