Chrome and Edge Patching, CISA KEV Activity, Android Zero-Day, and Notable CVEs
TL;DR - CISA added a new KEV item, and browser patching dominated today’s risk picture. - Chrome and Edge users should update immediately; admins should review exposed apps. - Urgency is high for browsers and internet-facing services.
Top Stories
1) CISA adds one vulnerability to the KEV catalog
CISA added one new vulnerability to its Known Exploited Vulnerabilities catalog based on evidence of active exploitation (CISA).
Why it matters:
A KEV addition is one of the clearest public signals that exploitation is not theoretical. For federal agencies, KEV entries usually trigger remediation deadlines. For everyone else, they should trigger prioritization reviews, especially where the affected product is internet-facing or widely deployed.
What to do next: - Check the latest KEV entry and map it against your asset inventory. - Validate whether the affected software is externally exposed. - Hunt for exploitation artifacts before and after patching. - If immediate patching is not possible, apply compensating controls and increase monitoring.
2) Chrome updates address multiple vulnerabilities
CISA published an alert that Google released Stable Channel updates for Chrome on desktop and Android to address multiple vulnerabilities (CISA).
Separately, reporting highlighted that Google fixed a Chrome zero-day capable of revealing users’ visited links (Google News / BleepingComputer), and additional coverage noted that Chrome patched three zero-days, including one under active exploitation (Google News / Dark Reading).
Why it matters:
Browser flaws remain one of the fastest paths from user activity to compromise. Even where the underlying bugs differ, the operational answer is the same: rapid browser patching beats detailed debate.
What to do next: - Force-update Chrome on managed endpoints. - Verify Android update coverage where enterprise mobility tools are in use. - Review EDR detections for browser child processes, script interpreters, and unusual renderer behavior. - Prioritize high-risk users first: admins, executives, developers, journalists, and support staff.
3) Chrome and Microsoft Edge both received security updates
CISA also flagged updates affecting both Google Chrome and Microsoft Edge (CISA).
Why it matters:
Many organizations assume Chromium-based browser risk is “handled” once Chrome is updated. In practice, Edge has separate release timing and packaging in some environments. If your fleet runs both, verify both.
What to do next: - Confirm browser versions via endpoint management, not user self-reporting. - Make sure auto-update services are enabled and not blocked by proxy or policy drift. - Review VDI, kiosk, and jump-host images that often lag behind user workstations.
4) Reported Android zero-day use in Serbian attacks
TechCrunch reporting syndicated through Google News said Paragon warned of an Android zero-day exploit used in Serbian attacks (Google News / TechCrunch).
Why it matters:
Mobile-device exploitation remains highly targeted but operationally significant. Even if your organization is not directly in scope, targeted exploit reporting should prompt a review of mobile logging, MDM coverage, and high-risk user protections.
What to do next: - Confirm MDM enrollment and update compliance for Android devices. - Revisit app install restrictions and USB debugging policy. - Identify users with elevated exposure who may need tighter mobile controls. - Preserve forensic options where mobile threat response is available.
5) Market signal: high-value Telegram exploit demand
Reporting also noted a Russian zero-day broker offering up to $4 million for Telegram exploits (Google News / TechCrunch).
Why it matters:
Even without a public exploit chain, exploit-buying activity is a useful directional indicator. It shows where sophisticated buyers see operational value and where defenders should expect future pressure.
What to do next: - Treat high-risk messaging platforms as sensitive applications in your threat model. - Keep device hardening and OS patching current for users handling sensitive comms. - Review DLP and MAM controls where supported.
6) Criminal use of leaked red-team tooling continues
BleepingComputer reporting, syndicated through Google News, said attackers are abusing a leaked copy of Shellter to spread infostealers and RATs (Google News / BleepingComputer).
Why it matters:
When offensive tools escape into commodity criminal use, defenders often see more evasion in otherwise familiar intrusion chains. Existing malware families become harder to detect with static controls alone.
What to do next: - Re-test detections against packed or evasive payload delivery. - Review AMSI, script-blocking, and memory-scanning telemetry. - Pay attention to LOLBin abuse after initial access.
Critical Vulnerabilities
CVE-2025-52990 : Pterodactyl arbitrary file exposure
- Severity: Critical, CVSS 9.8
- Published: 2025-05-27
- Affected: Pterodactyl before 1.11.11
- Summary: A crafted request to
/locales/locale.jsoncan expose arbitrary server files in the JSON response if they are readable by the web server process. - Source context: CVE data provided in the daily feed.
So what?
This is the kind of issue defenders should treat as internet-facing data exposure with low attacker friction. It is unauthenticated, impacts a popular open-source panel, and can disclose sensitive local files depending on permissions.
What to do next: 1. Upgrade to 1.11.11 immediately. 2. Restrict direct internet exposure while patching if feasible. 3. Review web server file permissions and ensure sensitive files are not readable by the frontend process. 4. Hunt for suspicious requests to the locale endpoint.
Technical Notes
Example access log pattern to review:
grep -R "GET /locales/locale.json" /var/log/nginx /var/log/apache2 2>/dev/null
Suspicious indicators to look for:
- Repeated requests to /locales/locale.json
- Unusual locale or namespace parameter values
- Requests from unfamiliar IPs followed by broader probing
Example quick triage with ripgrep:
rg -n "/locales/locale\.json|locale=|namespace=" /var/log/nginx /var/log/apache2
Nginx-style log filtering example:
awk '$7 ~ /\/locales\/locale\.json/ {print}' /var/log/nginx/access.log
CVE-2025-52897 : Apache SeaTunnel authenticated job submission issue
- Severity: High, CVSS 8.8
- Published: 2025-05-27
- Affected: 2.3.9 before 2.3.11, and 2.4.0 before 2.4.1
- Summary: In cluster mode with Rest API enabled, the
/hazelcast/rest/maps/submitJob/{jobName}endpoint does not verify admin status, allowing authenticated users to submit jobs that could lead to arbitrary code execution.
So what?
This is a dangerous “authenticated-to-code-execution” style weakness in data pipeline infrastructure. In environments where many users have platform access, the practical risk may be higher than the label suggests.
What to do next: 1. Upgrade to 2.3.11 or 2.4.1. 2. If the REST API is not required, disable or restrict it. 3. Audit which users can authenticate to SeaTunnel. 4. Review recent submitted jobs for unexpected names, parameters, or code paths.
Technical Notes
Look for requests hitting the vulnerable endpoint:
grep -R "/hazelcast/rest/maps/submitJob/" /var/log 2>/dev/null
Review service configuration for REST exposure:
rg -n "rest|hazelcast" /opt /etc 2>/dev/null
Example hardening approach:
- Restrict management/API interfaces to VPN or admin subnets
- Enforce least-privilege platform accounts
- Separate user access from administrative job execution where possible
CVE-2025-43859 : IBM PowerSC local privilege escalation
- Severity: High, CVSS 8.1
- Published: 2025-05-27
- Affected: IBM PowerSC
- Summary: A weak default
sudoersconfiguration may allow a local user with shell access to escalate to root.
So what?
This is not a remote bug, but it matters anywhere shell access is available to lower-trust users, contractors, or service accounts. In shared or admin-heavy environments, local privilege escalation quickly becomes a full-host compromise issue.
What to do next:
1. Apply IBM’s available fixes.
2. Restrict shell access to only those who need it.
3. Review sudoers and related include files for overly broad rules.
4. Hunt for suspicious sudo activity from non-admin users.
Technical Notes
Review sudo privileges:
sudo -l -U <username>
Inspect sudoers and included configs:
visudo -c
grep -Rin "NOPASSWD\|ALL=(ALL)\|ALL$" /etc/sudoers /etc/sudoers.d 2>/dev/null
Check auth logs for sudo escalation:
grep -Ei "sudo|COMMAND=" /var/log/auth.log /var/log/secure 2>/dev/null | tail -n 200
CVE-2025-2031 : Oh Dear WordPress plugin stored XSS
- Severity: High, CVSS 8.1
- Published: 2025-05-27
- Affected: Oh Dear plugin through 1.1.4
- Summary: Stored XSS via the
ohdearshortcode due to insufficient sanitization and output escaping. Authenticated users with Contributor-level access and above may inject script into pages.
So what?
This is especially relevant for sites with multiple authors or delegated content contributors. Contributor-level XSS often becomes session theft, admin action abuse, or malicious content injection.
What to do next:
1. Update the plugin when a fixed version is available from the maintainer.
2. Limit Contributor access where not necessary.
3. Review recently edited pages and posts containing the ohdear shortcode.
4. Invalidate potentially exposed admin sessions if suspicious edits are found.
Technical Notes
Search WordPress content for shortcode use:
wp post list --fields=ID,post_title,post_status --format=csv | head
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%[ohdear%';"
Review plugin inventory:
wp plugin list
Check web logs for admin actions after suspicious edits:
grep -Ei "wp-admin|post\.php|admin-ajax\.php" /var/log/nginx/access.log | tail -n 200
What Defenders Should Do Today
1) Patch browsers first
Today’s highest-confidence operational guidance is to update Chrome and Edge as quickly as your change process allows. CISA published alerts for Chrome and for Chrome-plus-Edge updates (Chrome alert, Chrome/Edge alert).
Priority order: - Admin workstations - Executives and high-risk users - Shared endpoints and VDI - General employee endpoints - Android managed devices
2) Review exposure to newly disclosed internet-facing app flaws
Pterodactyl and Discourse both deserve immediate review if exposed externally. SeaTunnel deserves review where the REST API is enabled.
Quick triage questions: - Is the application exposed to the internet? - Is it behind SSO, VPN, IP allowlists, or WAF controls? - Are anonymous or low-trust users able to interact with it? - Can your logs show exploitation attempts?
3) Tighten permissions and reduce anonymous interactions
Two themes recur in today’s disclosures: - Overly broad file or privilege access - Untrusted user interaction paths
Practical hardening steps:
- Remove unnecessary read access for web server processes.
- Review sudoers and shell access on Unix-like hosts.
- Reduce anonymous posting or unauthenticated interaction where platforms support it.
- Restrict management APIs to trusted networks.
4) Hunt for post-exploitation and suspicious web activity
Patch status is not enough if exploitation may already have happened.
Technical Notes
Example browser exploitation hunting ideas:
# Linux process history from audit/logging sources will vary by environment.
# Focus on child processes spawned by browser executables.
Windows-centric Defender/KQL concept:
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("chrome.exe","msedge.exe")
| where FileName in~ ("cmd.exe","powershell.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe")
Web log review concept:
# Look for unusual parameters, repeated probing, and 200 responses on sensitive endpoints
grep -E "/locales/locale\.json|/hazelcast/rest/maps/submitJob/|wp-admin|admin-ajax\.php" /var/log/nginx/access.log
Analyst Notes
A few caution points for today’s digest:
- The Chrome risk picture is strong because it is supported by CISA alerts and multiple independent media reports, but defenders should still anchor remediation to vendor and CISA guidance first.
- Reporting on Android zero-day activity and exploit-market pricing is useful for awareness and prioritization, but those items are less directly actionable than the browser and product CVEs listed above.
- Several of today’s notable CVEs affect open-source or admin-facing products that may sit outside standard enterprise patch cadences. That gap is where exposure often lingers.
Bottom Line
If you only have time for three actions today:
- Patch Chrome and Edge across managed endpoints.
- Check whether Pterodactyl, Discourse, or SeaTunnel are exposed in your environment.
- Review logs for suspicious web requests and abnormal privilege escalation activity.
The overall pattern for May 27 is familiar but important: active exploitation pressure, fast-moving browser fixes, and newly disclosed flaws in exposed management and community platforms. Speed, inventory accuracy, and focused log review matter more than perfect detail.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.