CVE-2019-6453

mIRC is an internet chat app, and this bug is about how it handles special “irc://” links that can come from emails or websites. In older versions (before 7.55), a harmful link can trick mIRC into loading a remote configuration file and running unintended actions—like giving an attacker control of what mIRC does on that computer. The risk is largely about whether your staff might click untrusted links and which software is used to open those links.

This matters to you if your business uses mIRC on employee computers and that software is reachable through normal user activity like opening links from email or websites. The exploit relies on how the “irc://” link is handled by the user’s browser/app; the findings note that Chrome is not exploitable. The practical risk is mainly if a crafted “irc://” link can be triggered on an affected mIRC version (before 7.55).

Treat this as important because working proof-of-concept code exists publicly, meaning attackers can test and adapt the technique. The issue is fixed in mIRC 7.55, but until devices are updated, a successful link-based trick could lead to remote command execution on the user’s machine.

1. Confirm exposure (per device):

   • Find the installed mIRC version on each workstation (and any server/VDI session) where mIRC is used.
   • Identify any version earlier than 7.55.

2. Confirm the likely trigger path:

   • Ask whether staff commonly click “irc://” links from email, PDFs, chat, or websites.
   • Note which browser/app is used to open links. The findings indicate Chrome is not exploitable, but other URI-handling paths may be.

3. Upgrade remediation:

   • Upgrade mIRC to 7.55 or later on every affected device.
   • Coordinate with IT to ensure settings/configuration are preserved if your users rely on custom mIRC settings.

4. Temporary workaround if you can’t upgrade immediately:

   • Reduce the chance of triggering the vulnerable path by discouraging or blocking untrusted “irc://” links from entering the environment (for example, tighter email link filtering, user guidance to not open unknown links, and restricting link sources).

5. Verification after changes:

   • Re-check mIRC versions after the upgrade rollout.
   • Look for any unusual mIRC behavior around the time of “irc://” link clicks (unexpected configuration loads, abnormal connection attempts, or crashes).

6. Ongoing monitoring:

   • If you have endpoint detection/response or centralized logging, set alerts for suspicious child processes or configuration/script-like activity launched from mIRC.

7. Coordination notes:

   • KEV listing is not present, so prioritize based on your exposure (mIRC version + link-click behavior), but still patch because publicly available PoC exists.

Severity is high (remote command execution) with a vulnerability rooted in custom URI handling (CWE-88: argument injection). The mechanism described in the findings is that a crafted “irc://” URI can lead mIRC (before 7.55) to load an attacker-controlled .ini file from a UNC share path, with the exploit depending on how the URI is handled by the browser/app (the findings specifically note Chrome is not exploitable). Public proof-of-concept code exists, indicating practical weaponization potential; KEV is not listed by CISA. The fix is available: mIRC 7.55.