Tag Archives: Adobe

May "In the Trend of VM" (#27): high-profile vulnerabilities in Linux, ActiveMQ, SharePoint, and Adobe Acrobat Reader

May In the Trend of VM (#27): high-profile vulnerabilities in Linux, ActiveMQ, SharePoint, and Adobe Acrobat Reader

May "In the Trend of VM" (#27): high-profile vulnerabilities in Linux, ActiveMQ, SharePoint, and Adobe Acrobat Reader. Presenting the traditional monthly roundup of trending vulnerabilities according to Positive Technologies. While the previous April edition featured only one vulnerability, this one includes four, covering different technologies and attack scenarios.

🗞 Post on Habr (rus)
🗒 Digest on the PT website (rus)

🔻 EoP - Linux Kernel "Copy Fail" (CVE-2026-31431). The vulnerability allows an attacker to gain root privileges.

🔻 RCE - Apache ActiveMQ (CVE-2026-34197). A vulnerability in a solution widely used in enterprise systems and integration platforms.

🔻 Spoofing - Microsoft SharePoint Server (CVE-2026-32201). A vulnerability in a Microsoft solution widely used in enterprise systems for collaboration, document management, and internal portal development.

🔻 RCE - Adobe Reader (CVE-2026-34621). A vulnerability in a widely used PDF document viewer; actively exploited in phishing attacks.

🟥 The full list of trending vulnerabilities is available on the portal

About Remote Code Execution - Adobe Reader (CVE-2026-34621) vulnerability

About Remote Code Execution - Adobe Reader (CVE-2026-34621) vulnerability

About Remote Code Execution - Adobe Reader (CVE-2026-34621) vulnerability. Adobe Acrobat Reader (from 2003 to 2015, "Adobe Reader") is a free PDF viewer developed by Adobe. Versions are available for Windows, macOS, Android, and iOS. The remote code execution vulnerability in Adobe Acrobat for Windows and macOS is caused by improper handling of object prototype attributes (CWE-1321 - "Prototype Pollution"). Successful exploitation of the vulnerability allows an attacker to execute arbitrary code on the target system when the victim opens a specially crafted document.

👾 Researcher Haifei Li, the developer of EXPMON - a sandbox-based system designed to detect file-based zero-days and hard-to-detect exploits - reported the vulnerability and the existence of a working exploit on April 7. Earlier, on March 26, an unknown individual uploaded a malicious PDF sample named yummy_adobe_exploit_uwu.pdf to the public EXPMON service.

According to the analysis results, the sample behaved like an initial exploit capable of collecting and transmitting various types of information to the attacker, potentially followed by arbitrary code execution (RCE) and sandbox escape (SBX) exploits. It used a zero-day vulnerability in Adobe Reader that allowed it to invoke privileged Acrobat APIs. The exploit was confirmed to work on the latest version of Acrobat. Specifically, it abused the "util.readFileIntoStream()" API, which allows arbitrary files accessible to the isolated Reader process to be read from the local system. This enabled the malware to collect a wide range of information from the victim's machine and steal data from local files. The "RSS.addFeed()" API was used to send the collected information to a remote server and retrieve additional JavaScript code for execution. Such a mechanism allows attackers to gather user information, steal local data, perform advanced fingerprinting, and further develop the attack. If the target matched the attacker's criteria, an additional exploit could then be delivered to achieve RCE or SBX. However, during testing, the researcher was unable to obtain the additional exploit payload - although the server was reachable, it did not respond. This may have been caused by several factors. For example, the local testing environments may not have matched the specific criteria expected by the attacker.

On April 8, another malicious file sample was discovered on VirusTotal. The file had originally been uploaded on November 28, 2025, indicating that this 0day/APT campaign had been active for at least four months.

On April 9, researcher Gi7w0rm reported signs of active exploitation of the vulnerability in attacks. The attacks used malicious Russian-language documents disguised as materials related to Russia's oil and gas sector as phishing lures. Based on the observed targeting, the campaign appears to have been aimed at specific Russian organizations.

On April 13, the vulnerability was added to the CISA KEV catalog.

⚙️ The Adobe security bulletin was published on April 12. Affected versions include Acrobat DC 26.001.21367 and earlier, Acrobat Reader DC 26.001.21367 and earlier, and Acrobat 2024 24.001.30356 and earlier. The vulnerability has been fixed in Acrobat DC 26.001.21411, Acrobat Reader DC 26.001.21411, and Acrobat 2024 (Windows: 24.001.30362/Mac: 24.001.30360).

Adobe recommends that users of affected versions update their applications via “Help > Check for Updates”, which triggers the automatic update process. Alternatively, users can download the Acrobat Reader installer directly from Adobe's official portal.

The bulletin notes that Adobe is aware of active exploitation of vulnerability CVE-2026-34621 in the wild.

🛠 No public exploits have been observed so far.

💡 PDF files received from untrusted or unexpected sources should always be treated with caution and opened in isolated (sandboxed) environments. 😉

Last Week’s Security news: Exploits for ForgeRock, vSphere, Apache Tomcat, new Print Spooler vuln, Kaseya Patch and REvil, SolarWinds, Schneider Electric, Bulletins

Last Week’s Security news: Exploits for ForgeRock, vSphere, Apache Tomcat, new Print Spooler vuln, Kaseya Patch and REvil, SolarWinds, Schneider Electric, Bulletins. Hello guys! The fourth episode of Last Week’s Security news, July 12 – July 18.

I would like to start with some new public exploits. I think these 4 are the most interesting.

  • If you remember, 2 weeks ago I mentioned the ForgeRock Access Manager and OpenAM vulnerability (CVE-2021-35464). Now there is a public RCE exploit for it. ForgeRock OpenAM server is a popular access management solution for web applications. Michael Stepankin, Researcher: “In short, RCE is possible thanks to unsafe Java deserialization in the Jato framework used by OpenAM”. And now this vulnerability is Under Active Attack. “The [Australian Cyber Security Centre] has observed actors exploiting this vulnerability to compromise multiple hosts and deploy additional malware and tools,” the organization said in an alert. ACSC didn’t disclose the nature of the attacks, how widespread they are, or the identities of the threat actors exploiting them”.
  • A new exploit for vSphere Client (CVE-2021-21985). The vSphere Client (HTML5) contains a remote code execution vulnerability due to lack of input validation in the Virtual SAN Health Check plug-in which is enabled by default in vCenter Server. A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server.
  • Apache Tomcat 9.0.0.M1 – Open Redirect (CVE-2018-11784). “When the default servlet in Apache Tomcat […] returned a redirect to a directory […] a specially crafted URL could be used to cause the redirect to be generated to any URI of the attackers choice”.
  • Apache Tomcat 9.0.0.M1 – Cross-Site Scripting (CVE-2019-0221). “The SSI printenv command in Apache Tomcat […] echoes user provided data without escaping and is, therefore, vulnerable to XSS”. However, in real life this is unlikely to be used. “SSI is disabled by default. The printenv command is intended for debugging and is unlikely to be present in a production website”.

Continue reading

Petya the Great and why *they* don't patch vulnerabilities

Petya the Great and why *they* don’t patch vulnerabilities. I really like this. Just imagine. Quiet, routine, everyday Vulnerability Management process in organizations: scanning-patching, scanning-patching, scanning-patching… And then. Suddenly! PEEETYYA!!!

And at very same moment everything changes. People from different companies start to communicate with each other actively, reverse this new malware, share the data, write and share tools for detection and recovery. Security professional is a friend, a brother and a source of useful information for security professional. Real movement! Real community! =)

Petya ransomware

For example, my friends from Vulners.com created pretty popular gist about Petya (petrWrap, notPetya, GoldenEye) and updated in real time for several hours.

Vulners Petya gist

My former colleagues from Positive Technologies released detailed technical review of this ransomware (in Russian) few hours since the outbreak started, at 01:00 am . They also found a local kill switch, and probably were the first one. Simultaneously with Amit Serper from Cybereason.

Continue reading

Forever "reserved" CVEs

Forever “reserved” CVEs. In this post I would like to provide some links, that you can use to find out necessary information about vulnerability by its CVE ID. I also want to share my amazement, how the method of using the CVE identifiers is changing.

Reserved CVE

Traditionally, CVE was a global identifier that most of vulnerabilities had. Have you found malicious bug in some software? Send a brief description to MITRE and you will receive CVE id. Some time later NIST will analyze this CVE, will add CVSS vector and CPEs and will put a new item to the NVD database. MITRE and NVD CVE databases were really useful source of information.

Continue reading