Shared object path traversal allows writes outside app folder

Severity: Critical

Affected versions: WSE 4.12.1 and earlier

Fixed in: WSE 4.12.2

Known exploitation in the wild: None

What to do: Upgrade to Wowza Streaming Engine 4.12.2 or later. Upgrading is the only complete fix.

Summary

A remote client that can connect to a Wowza Streaming Engine (WSE) application with SharedObjects enabled can make the server write files outside that application’s SharedObject storage folder, using the WSE process’s privileges.

This can lead to remote code execution as the WSE service user, and to full compromise of the host, its media, credentials and configuration.

Am I affected?

You’re affected if both of these are true:

• You run WSE 4.12.1 or earlier.
• Any application allows SharedObject writes. The default application templates do.

Your risk is lower if your applications don’t allow SharedObjects, or if your server isn’t reachable by untrusted clients.

If you can’t upgrade yet

These steps reduce your risk but don’t fully fix the vulnerability. Plan to upgrade as soon as you can.

1. Disable remote shared objects

Set SharedObjectReadAccess and SharedObjectWriteAccess to empty values in every application’s Application.xml and in the template, then restart the server.

• Each application: [install-dir]/conf/[app-name]/Application.xml
• Template: [install-dir]/conf/Application.xml

<!-- Inside <Application> in Application.xml -->
<Client>
    <Access>
        <SharedObjectReadAccess></SharedObjectReadAccess>
        <SharedObjectWriteAccess></SharedObjectWriteAccess>
    </Access>
</Client>

Note: Remote shared objects are deprecated. They were built for Adobe Flash Player, which is no longer supported. Unless a legacy RTMP client depends on them, it’s safe to disable them.

2. Run WSE and WSE Manager as unprivileged users

Run each under its own dedicated service account instead of root. If an attacker succeeds, they’re limited to that account’s privileges. See Run Wowza Streaming Engine as a named user.

3. Tighten firewall rules

Block or limit access to non-streaming ports, and rate-limit how fast a single client can open socket connections.

4. Shorten the unidentified session timeout

Lower UnidentifiedSessionTimeout in VHost.xml from 30000 ms to 10000 ms so unauthenticated sessions can’t hold server resources as long.

<!-- Inside <VHost> in VHost.xml -->
<Application>
    <UnidentifiedSessionTimeout>10000</UnidentifiedSessionTimeout>
</Application>

5. Bind the CommandInterface to localhost

In Server.xml, set the CommandInterface IP address to 127.0.0.1 so external hosts can’t connect to it directly.

<!-- Inside <Server> in Server.xml -->
<CommandInterface>
    <HostPort>
        <IpAddress>127.0.0.1</IpAddress>
    </HostPort>
</CommandInterface>

Checking for signs of exploitation

SharedObject files belong only in [install-dir]/applications/[app-name]/sharedobjects/[app-inst-name]. Look for any of the following elsewhere on the server, especially directly under [install-dir]/:

• Unexpected .rso files
• Files with any extension that contain Remote Shared Object (RSO) XML

If you find something suspicious, compare its timestamp with RTMP connection events in the server logs to identify related activity and client IP addresses.

Logs may also show SharedObject errors from failed writes or from loading malformed .rso files. These can support an investigation but don’t on their own confirm a successful attack.

Disclosure timeline

• Oct 12, 2026: Wowza received the report.
• Oct 30, 2026: Wowza released WSE 4.12.2 and published this advisory.

Credits

• Hacktron

References

• Wowza Streaming Engine 4.12.2 release notes
• Application.xml configuration reference
• Server.xml configuration reference