Admin privilege escalation and arbitrary code execution via malicious *.etherpad imports
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 1.8.16
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Etherpad is a real-time collaborative editor. In versions prior to 1.8.16, an attacker can craft an `*.etherpad` file that, when imported, might allow the attacker to gain admin privileges for the Etherpad instance. This, in turn, can be used to install a malicious Etherpad plugin that can execute arbitrary code (including system commands). To gain privileges, the attacker must be able to trigger deletion of `express-session` state or wait for old `express-session` state to be cleaned up. Core Etherpad does not delete any `express-session` state, so the only known attacks require either a plugin that can delete session state or a custom cleanup process (such as a cron job that deletes old `sessionstorage:*` records). The problem has been fixed in version 1.8.16. If users cannot upgrade to 1.8.16 or install patches manually, several workarounds are available. Users may configure their reverse proxies to reject requests to `/p/*/import`, which will block all imports, not just `*.etherpad` imports; limit all users to read-only access; and/or prevent the reuse of `express_sid` cookie values that refer to deleted express-session state. More detailed information and general mitigation strategies may be found in the GitHub Security Advisory.
Timeline
- CVE published
- Record last updated
Affected versions
- ether etherpad-lite
fixed in 1.8.16