Mitel MiVoice Office 400: Shared Object Hijacking Leading to Arbitrary Code Execution

Overview

A shared object hijacking vulnerability exists in Mitel MiVoice Office 400, potentially allowing an attacker with authenticated administrative access to the web management interface to execute arbitrary code as root on the underlying Linux operating system. The vulnerability originates from insufficient access controls in the application's web-based file management functionality, which may allow users to modify files in directories containing executable binaries and shared libraries (.so). By influencing the files loaded by a privileged process, an attacker may escalate privileges from web interface administration to root-level access on the underlying system.

In an email dated September 14, 2026, at 18:08, Mitel's Product Security Incident Response Team (PSIRT) declined remediation, arguing that exploitation requires authenticated administrative access and that administrators are already authorized to upload, modify, and manage files. However, this reasoning does not address the fundamental security issue: authorization to administer an application does not inherently justify unrestricted access to operating system directories or the ability to modify executable components loaded by privileged processes. The issue is not simply that an administrator can manage files, but that the application's file management functionality may expose filesystem locations that should not be writable through the web interface. By treating the authentication requirement as sufficient justification, Mitel's response fails to address the privilege boundary that the vulnerability potentially compromises.

As of the publication of this report, no security patch has been made available, and Mitel's PSIRT has indicated that it does not intend to remediate the reported behavior. Organizations operating affected systems should therefore implement compensating security measures.

The primary recommendation is to restrict access to the MiVoice Office 400 management interface to trusted personnel with explicit IT infrastructure or security administration responsibilities. Organizations should additionally isolate the management interface on a restricted network, review administrative accounts, and monitor access to the system.

These measures do not eliminate the underlying vulnerability. Until an effective remediation becomes available, restricting access to the management interface is the principal recommended mitigation.

Video: For the sake of transparency, we have created a video demonstrating the hijacking process, from system startup to full compromise. Feel free to skip to 5:20, where the hijacking process begins, and watch how the compromise is completed after the virtual machine reboots.

Objective

The objective was to reconstruct a replacement for the proprietary 32-bit ELF shared library libXfTftpd.so so that the existing MSRV application could load the library and continue through its initialization path.

The primary requirement was runtime compatibility with the existing application rather than reproducing the complete original TFTP implementation.

Target environment

The target system is an embedded Linux environment running on 32-bit x86. The following processes were observed on the target.

root  2198  ... /home/mivo400/sw/lm/swit
root  2199  ... /home/mivo400/sw/lm/cmgr
root  2200  ... /home/mivo400/sw/lm/fmgr
root  2201  ... /home/mivo400/sw/lm/msrv

Build environment

A separate Oracle Linux build environment was prepared to generate a shared object compatible with the target system. The critical requirement was matching the target ABI rather than producing the default x86-64 ELF64 output.

Architecture verification

file libXfTftpd.so
readelf -h libXfTftpd.so

Initial analysis of the original library

The original library was inspected using ELF symbol inspection and disassembly tools. The exported functions were identified using nm.

nm -D -C libXfTftpd.so | grep -E \
'CreateFileCb|CreateMemoryCb|FreeCbMemory|QueryFileCbTransfered|QueryMemoryCbTransfered|StopFileCbTransfer|StopMemoryCbTransfer|XfTftpGet'

This established the externally visible API expected from libXfTftpd.so and the initial compatibility boundary for the reconstruction.

CreateFileCb analysis

The original CreateFileCb implementation was examined using disassembly.

000023e0 <CreateFileCb>:
23e0: 56                   push esi
23e1: 53                   push ebx
23e2: 83 ec 14             sub  esp,0x14
23e5: c7 04 24 20 00 00 00 mov  DWORD PTR [esp],0x20
23ec: 8b 74 24 24          mov  esi,DWORD PTR [esp+0x24]
23f0: e8 fc ff ff ff       call ...
23f5: c7 40 08 0c 00 00 00 mov  DWORD PTR [eax+0x8],0xc
23fc: 89 c3                mov  ebx,eax
23fe: c7 40 04 00 00 00 00 mov  DWORD PTR [eax+0x4],0x0
...
2424: c7 43 0c 00 00 00 00 mov  DWORD PTR [ebx+0xc],0x0
242b: c6 03 00             mov  BYTE PTR [ebx],0x0
242e: c6 43 01 01          mov  BYTE PTR [ebx+0x1],0x1
2432: 89 18                mov  DWORD PTR [eax],ebx
2437: b8 00 00 00 00       mov  eax,0x0
243e: c3                   ret

The function allocates and initializes a callback structure and returns zero. The caller expects an output pointer to be populated rather than receiving the object directly as the return value.

CreateMemoryCb analysis

The second callback constructor was inspected to understand how the original library initializes its memory-transfer callback.

00002440 <CreateMemoryCb>:
2440: 56                   push esi
2441: 53                   push ebx
2442: 83 ec 14             sub  esp,0x14
2445: c7 04 24 20 00 00 00 mov  DWORD PTR [esp],0x20
244c: 8b 5c 24 24          mov  ebx,DWORD PTR [esp+0x24]
2450: 8b 74 24 28          mov  esi,DWORD PTR [esp+0x28]
...
245d: c7 40 08 0c 00 00 00 mov  DWORD PTR [eax+0x8],0xc
2464: c6 00 00             mov  BYTE PTR [eax],0x0
2467: c6 40 01 01          mov  BYTE PTR [eax+0x1],0x1
246b: 89 02                mov  DWORD PTR [edx],eax
246f: 8b 16                mov  edx,DWORD PTR [esi]
2472: 89 58 14             mov  DWORD PTR [eax+0x14],ebx
2475: 89 70 1c             mov  DWORD PTR [eax+0x1c],esi
...
247e: b8 00 00 00 00       mov  eax,0x0
2485: c3                   ret

CreateMemoryCb similarly allocates and initializes a callback object and stores the resulting pointer through an output parameter.

Important callback API

The compatibility requirement was to preserve the names, visibility and calling conventions expected by the existing compiled components.

Analysis of libSL_SDK_HMPd.so

The second library involved in the observed call chain was libSL_SDK_HMPd.so. The relevant function was F2BSpImpl::StartFilePlayback(...).

readelf -r libSL_SDK_HMPd.so |
grep -E 'CreateFileCb|FreeCbMemory|XfTftpGet'

These relocations demonstrate that the MSRV-side components reference the expected symbols. A relocation establishes a binary reference, but does not prove that the function executes during every runtime session.

Call-site analysis

objdump -d -M intel \
--start-address=0x1a7d20 \
--stop-address=0x1a7da6 \
libSL_SDK_HMPd.so

The disassembly shows argument preparation and a call associated with the relocation for CreateFileCb. Later instructions prepare arguments for XfTftpGet, followed by a call associated with FreeCbMemory.

Why symbol compatibility matters

The application was not rebuilt. The ABI boundary was therefore determined by the existing binaries.

The goal was not to reproduce every internal implementation detail of the proprietary library, but to understand the observable behavior at the binary interface.

Runtime verification

Confirm the process

ps -ef | grep msrv

Confirm the library mapping

grep -F 'libXfTftpd.so' /proc/2201/maps

Observed mappings

f58c3000-f58c4000 r-xp 00000000 fd:01 659871
/home/mivo400/sw/msrv/lib/libXfTftpd.so

f58c4000-f58c5000 r--p 00000000 fd:01 659871
/home/mivo400/sw/msrv/lib/libXfTftpd.so

f58c5000-f58c6000 rw-p 00001000 fd:01 659871
/home/mivo400/sw/msrv/lib/libXfTftpd.so

The mappings demonstrate that the shared object was mapped by the process. They do not independently prove that a specific exported function or initialization routine executed.

Early execution test

A simple filesystem observation was considered as an initial proof-of-execution mechanism. This avoids introducing network connectivity, listener readiness and connection timing as additional variables during the first stage of validation.

Current validation state

References

The following sources provide the vulnerability record, official Swiss CVE information and DigitalCanion's research listing.

Conclusion

The reconstruction process moved the investigation from static reverse engineering to runtime validation of the replacement shared object.

The key result was not merely obtaining a syntactically valid shared library. The replacement was placed at the application's expected library path and was observed directly in the existing 32-bit MSRV process address space.

Static analysis also established the relevant binary interface between libSL_SDK_HMPd.so and libXfTftpd.so, including references to CreateFileCb, XfTftpGet and FreeCbMemory.