All modern Hyperion / Oracle EPM systems use the Apache log4j library behind the scenes. On December 10, 2021, a zero-day exploit was revealed and attackers in the wild are already scanning vulnerable systems.
Systems running Apache log4j 2.0-beta9 up to 2.14.1 are impacted.
EPM 11.2.x uses log4j 2.13.3, according to Oracle's 3rd Party Acknowledgements document for EPM. In truth, I'm seeing many log4j versions in my unpatched EPM 11.2.7 sandbox. I'll want to apply the October 2021 Critical Patch Update in my sandbox to see if this changes before I smash the Panic Button. A search for log4j*.jar in \Oracle\Middleware reveals the following:
EPM versions 11.1.2.x may use a slightly older version, but it would still be in the range of impacted versions.
The exploit allows the attacker to completely take over a server without needing credentials of any kind, other than finding their way into your network when your EPM system is behind a corporate firewall. This "get inside the network" scenario is not as far-fetched as it sounds, unless your IT Security folks have implemented 2-factor security on the VPN. We then get into a "social engineering" discussion, which I won't launch into here.
I can't view the code for Oracle's EPM Cloud, so I can't say for sure if the cloud is impacted. My gut tells me the EPM Cloud is based upon on-premises EPM technology in some fashion - Apache 2.0 and Oracle WebLogic for sure (why re-invent the wheel?). If the cloud URL is not protected (many EPM Cloud customers nowadays DO protect their URL so only folks inside their network may hit the URL, which is a GOOD thing), then there may be an issue here.
The BleepingComputer.com link which begins this article offers some suggestions. One is to patch log4j to log4j 2.15.0. Based upon my screenshot above, we'd have to do this in multiple places where the version is less than this. (Which according to my scan, is all of them). My gut tells me this effort would not be trivial, as we'd have to touch every EPM server having these directories.
A simpler fix may be to apply one of these changes suggested by BleepingComputer:
The flaw can also be mitigated in previous releases (2.10 and later) by setting system property "log4j2.formatMsgNoLookups" to "true" or removing the JndiLookup class from the classpath.
In the case of Windows-hosted EPM systems, we're talking about editing setdomainenv.bat in user_projects\domains\EPMSystem\bin so the WebLogic Admin Server has an additional -D argument for the Java options, and editing the Windows Registry on each Windows server for each Weblogic Managed Server underneath the "Hyperion Solutions" registry hive. Fun times. Actually not "simple", but you're not going out and patching multiple directories across multiple servers.
I suspect many of my readers won't have an appetite for this level of "surgery". The next Oracle Critical Patch Update is due in mid-January 2022, but only for those on EPM 11.2.x. Those of you still on EPM 11.1.2.x with no immediate plans to upgrade or move to the EPM Cloud may consider the surgery I mentioned above.
Those of us on EPM 11.2.x can hop out to Oracle's support site and search for the various Oracle Fusion Middleware patches. The patches will likely come out before the next Critical Patch Update is formally announced in mid-January.
Disclaimer: This blog post is speculative and may become dated after the January 2022 Critical Patch Update. I am not an employee of Oracle Corporation and thus do not speak for them.
Dec 12, 2021 Update:
The Apache Foundation has released a patched Java .jar file for log4j that claims to fix the issue. I'll try it in my sandbox later today to verify it doesn't brick things.