CWE-618: Exposed Unsafe ActiveX Method

Overview

ActiveX controls marked "safe for scripting" expose their methods directly to script on the hosting page without a trust boundary check. Any page rendered by the legacy engine, not only the developer's own site, can then invoke operations such as file access, command execution, or registry modification.

The IE11 desktop app was retired on 15 June 2022, so the only remaining surface is IE mode in Microsoft Edge, which still instantiates ActiveX controls and is supported through at least 2029. That surface is an enterprise-configured list rather than the open web: only sites you specifically configure use IE mode, and everything else renders as a modern site, either listed in the Enterprise Mode Site List XML applied by policy or covered by the "Send all intranet sites to Internet Explorer" policy. The ad-hoc "Reload in Internet Explorer mode" route narrowed further in Edge 141 and 142, which removed the menu item and the toolbar button. A non-managed user now has to enable the setting and add the specific site to their own IE-mode pages list. Exposure is bounded by that list, and the bound cuts both ways: a control reached only through IE mode is on a dated clock, and removal should be planned against it.

Relationship to Other CWEs

CWE-618 is a specific case of CWE-749 (Exposed Dangerous Method or Function), the general weakness of exposing privileged functionality without an access check, applied here to ActiveX controls marked safe for scripting. It is closely related to CWE-623 (Unsafe ActiveX Control Marked Safe For Scripting), which covers the control-level marking rather than the individual exposed method.

OWASP Classification

A01:2025 - Broken Access Control

Risk

Critical: Unsafe ActiveX methods allow remote code execution, arbitrary file read and write, and registry manipulation for any user who loads a page carrying attacker-controlled script in the legacy engine. No authentication is needed, and no user interaction beyond loading the page. The IE-mode site list bounds who can be reached, not what happens when they are.

Remediation Steps

Core Principle: Do not expose privileged operations to scripting from untrusted origins; the correct long-term fix is to remove ActiveX entirely and use sandboxed web-platform APIs instead.

Locate Unsafe ActiveX Controls

Search for <object classid="clsid:..."> tags and ActiveX registration code
Check whether the control's IObjectSafety implementation honors or ignores INTERFACESAFE_FOR_UNTRUSTED_CALLER
Work out which methods on the control are callable from JavaScript, and which of those are dangerous: file operations, command execution, registry access

grep -r "classid:clsid" --include="*.html"
grep -r "IObjectSafety\|INTERFACESAFE_FOR_UNTRUSTED" --include="*.cpp"

Remove ActiveX and Migrate to Web-Platform APIs (Primary Defense)

ActiveX has no secure configuration for exposure to the open web, so the only durable fix is removal. Almost every capability an ActiveX control historically provided has a sandboxed, browser-enforced equivalent - the exception is the last row, and it is worth knowing which you are choosing:

ActiveX capability	Modern replacement
File read/write	File API, File System Access API (user-initiated, sandboxed)
Cryptography	Web Crypto API
Hardware access	WebUSB, WebBluetooth, WebHID
Local data storage	IndexedDB, localStorage
Native OS integration	A Progressive Web App stays inside the browser sandbox; a WebExtension widens it to a reviewed permission set; Electron sandboxes its renderers by default and routes native work to a privileged main process over IPC, so the boundary becomes the IPC surface you choose to expose - and the bundled engine is yours to patch

If ActiveX Cannot Be Removed Immediately (Interim Mitigation)

Order matters here. Changing what the control claims about itself only affects builds shipped from now on. Copies already registered on users' machines keep answering scripted calls until something stops the browser instantiating them.

Set the kill bit for copies already deployed. Under HKLM\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{CLSID}, create a Compatibility Flags DWORD with the value 0x00000400. With that value present the browser will never instantiate that CLSID, whatever the control says about its own safety. Distribute it by group policy so it reaches machines you do not build images for.
Use the SiteLock ATL template if the control has to keep working. SiteLock makes the control compare the hosting page's scheme and fully-qualified domain name against a list compiled into it, and report itself unsafe for scripting anywhere else. That converts "any page can call these methods" into "only your pages can", which is what makes the per-method validation below a backstop rather than the control you are relying on.
Mark new builds unsafe for scripting: do not implement IObjectSafety to grant INTERFACESAFE_FOR_UNTRUSTED_CALLER, or explicitly deny it. This only helps installations that happen after the change ships.
Remove the most dangerous methods entirely. Arbitrary command execution (ExecuteCommand) has no safe implementation and should return "not implemented" rather than be guarded
Validate every remaining exposed method: canonicalize and allowlist file paths, reject path traversal sequences, block executable file extensions, cap input size, and restrict registry access to a specific, narrow key prefix
Log every invocation with the calling page's origin, so the calls are available to detection and incident response
Treat this as a bridge to removal rather than a permanent state. IE mode in Edge is the only surface the control still has, Microsoft commits to it through at least 2029, and end of support carries a minimum of one year's notice

Test the Fix

Confirm dangerous methods reject invocation from a test page (ExecuteCommand, WriteFile with a traversal path) and log the attempt
Confirm the application functions correctly using the web-platform replacement in all supported browsers
Re-scan with the security scanner to confirm no ActiveX object tags or CLSID references remain

Common Vulnerable Patterns

// VULNERABLE - pseudo-code
// object tag loads a control marked safe for scripting
control = load_activex_control(clsid)

// any page rendered by the legacy engine can call these directly
control.execute_command("cmd.exe /c format C:")   // remote code execution
control.write_file("C:\\Windows\\System32\\evil.dll", data)
control.set_registry_key("HKLM\\Software\\...", value)

Why this is vulnerable: "Safe for scripting" is an unverified claim by the control author that no method it exposes can do harm when called by an arbitrary page. The browser takes the claim at face value; nothing checks it. Any page the legacy engine renders can call these methods with the same privileges as the logged-in user. Under IE11 that was every site the browser visited. Under Edge's IE mode it is the configured site list, so the realistic route in is a cross-site scripting flaw on one of those sites, a third-party script one of them loads, or a same-site page an attacker can get content onto. That is why the SiteLock template described above narrows the surface rather than fixing the weakness.

Secure Patterns

// SECURE - pseudo-code, sandboxed web-platform API instead of ActiveX
file_input.on("change", (event) => {
    file = event.selected_file      // user explicitly chose this file
    content = read_as_text(file)    // sandboxed, no filesystem access outside selection
    process(content)
})

Why this works: The browser's file API only ever exposes a file the user explicitly selected through a native picker. Whatever script runs on the page, it cannot read arbitrary files, execute commands, or touch the registry. The boundary is enforced by the browser rather than by application-level checks that a control author could get wrong.