securityaffairs.com
October 04, 2025
Pierluigi Paganini
GreyNoise saw a 500% spike in scans on Palo Alto Networks login portals on Oct. 3, 2025, the highest in three months.
Cybersecurity firm GreyNoise reported a 500% surge in scans targeting Palo Alto Networks login portals on October 3, 2025, marking the highest activity in three months.
On October 3, the researchers observed that over 1,285 IPs scanned Palo Alto portals, up from a usual 200. The experts reported that 93% of the IPs were suspicious, 7% malicious.
Most originated from the U.S., with smaller clusters in the U.K., Netherlands, Canada, and Russia.
GryNoise defined the traffic targeted and structured, aimed at Palo Alto login portals and split across distinct scanning clusters.
The scans targeted emulated Palo Alto profiles, focusing mainly on U.S. and Pakistan systems, indicating coordinated, targeted reconnaissance.
GreyNoise found that recent Palo Alto scanning mirrors Cisco ASA activity, showing regional clustering and shared TLS fingerprints linked to the Netherlands infrastructure. Both used similar tools, suggesting possible shared infrastructure or operators. The overlap follows a Cisco ASA scanning surge preceding the disclosure of two zero-day vulnerabilities.
“Both Cisco ASA and Palo Alto login scanning traffic in the past 48 hours share a dominant TLS fingerprint tied to infrastructure in the Netherlands. This comes after GreyNoise initially reported an ASA scanning surge before Cisco’s disclosure of two ASA zero-days.” reads the report published by Grey Noise. “In addition to a possible connection to ongoing Cisco ASA scanning, GreyNoise identified concurrent surges across remote access services. While suspicious, we are unsure if this activity is related. “
GreyNoise noted in July spikes in Palo Alto scans sometimes preceded new flaws within six weeks; The experts are monitoring if the latest surge signals another disclosure.
“GreyNoise is developing an enhanced dynamic IP blocklist to help defenders take faster action on emerging threats.” concludes the report.
discord.com
Discord
October 3, 2025
At Discord, protecting the privacy and security of our users is a top priority. That’s why it’s important to us that we’re transparent with them about events that impact their personal information.
Discord recently discovered an incident where an unauthorized party compromised one of Discord’s third-party customer service providers.
This incident impacted a limited number of users who had communicated with our Customer Support or Trust & Safety teams.
This unauthorized party did not gain access to Discord directly.
No messages or activities were accessed beyond what users may have discussed with Customer Support or Trust & Safety agents.
We immediately revoked the customer support provider’s access to our ticketing system and continue to investigate this matter.
We’re working closely with law enforcement to investigate this matter.
We are in the process of emailing the users impacted.
At Discord, protecting the privacy and security of our users is a top priority. That’s why it’s important to us that we’re transparent with them about events that impact their personal information.
Recently, we discovered an incident where an unauthorized party compromised one of Discord’s third-party customer service providers. The unauthorized party then gained access to information from a limited number of users who had contacted Discord through our Customer Support and/or Trust & Safety teams.
As soon as we became aware of this attack, we took immediate steps to address the situation. This included revoking the customer support provider’s access to our ticketing system, launching an internal investigation, engaging a leading computer forensics firm to support our investigation and remediation efforts, and engaging law enforcement.
We are in the process of contacting impacted users. If you were impacted, you will receive an email from noreply@discord.com. We will not contact you about this incident via phone – official Discord communications channels are limited to emails from noreply@discord.com.
What happened?
An unauthorized party targeted our third-party customer support services to access user data, with a view to extort a financial ransom from Discord.
What data was involved?
The data that may have been impacted was related to our customer service system. This may include:
Name, Discord username, email and other contact details if provided to Discord customer support
Limited billing information such as payment type, the last four digits of your credit card, and purchase history if associated with your account
IP addresses
Messages with our customer service agents
Limited corporate data (training materials, internal presentations)
The unauthorized party also gained access to a small number of government‑ID images (e.g., driver’s license, passport) from users who had appealed an age determination. If your ID may have been accessed, that will be specified in the email you receive.
What data was not involved?
Full credit card numbers or CCV codes
Messages or activity on Discord beyond what users may have discussed with customer support
Passwords or authentication data
What are we doing about this?
Discord has and will continue to take all appropriate steps in response to this situation. As standard, we will continue to frequently audit our third-party systems to ensure they meet our security and privacy standards. In addition, we have:
Notified relevant data protection authorities.
Proactively engaged with law enforcement to investigate this attack.
Reviewed our threat detection systems and security controls for third-party support providers.
Taking next steps
Looking ahead, we recommend impacted users stay alert when receiving messages or other communication that may seem suspicious. We have service agents on hand to answer questions and provide additional support.
We take our responsibility to protect your personal data seriously and understand the inconvenience and concern this may cause.
theregister.com • The Register
by Jessica Lyons
Wed 1 Oct 2025 // 19:35 UTC
: Who wouldn't want root access on cluster master nodes?
9.9 out of 10 severity bug in Red Hat's OpenShift AI service could allow a remote attacker with minimal authentication to steal data, disrupt services, and fully hijack the platform.
"A low-privileged attacker with access to an authenticated account, for example as a data scientist using a standard Jupyter notebook, can escalate their privileges to a full cluster administrator," the IBM subsidiary warned in a security alert published earlier this week.
"This allows for the complete compromise of the cluster's confidentiality, integrity, and availability," the alert continues. "The attacker can steal sensitive data, disrupt all services, and take control of the underlying infrastructure, leading to a total breach of the platform and all applications hosted on it."
Red Hat deemed the vulnerability, tracked as CVE-2025-10725, "important" despite its 9.9 CVSS score, which garners a critical-severity rating from the National Vulnerability Database - and basically any other organization that issues CVEs. This, the vendor explained, is because the flaw requires some level of authentication, albeit minimal, for an attacker to jeopardize the hybrid cloud environment.
Users can mitigate the flaw by removing the ClusterRoleBinding that links the kueue-batch-user-role ClusterRole with the system:authenticated group. "The permission to create jobs should be granted on a more granular, as-needed basis to specific users or groups, adhering to the principle of least privilege," Red Hat added.
Additionally, the vendor suggests not granting broad permissions to system-level groups.
Red Hat didn't immediately respond to The Register's inquiries, including if the CVE has been exploited. We will update this story as soon as we receive any additional information.
Whose role is it anyway?
OpenShift AI is an open platform for building and managing AI applications across hybrid cloud environments.
As noted earlier, it includes a ClusterRole named "kueue-batch-user-role." The security issue here exists because this role is incorrectly bound to the system:authenticated group.
"This grants any authenticated entity, including low-privileged service accounts for user workbenches, the permission to create OpenShift Jobs in any namespace," according to a Bugzilla flaw-tracking report.
One of these low-privileged accounts could abuse this to schedule a malicious job in a privileged namespace, configure it to run with a high-privilege ServiceAccount, exfiltrate that ServiceAccount token, and then "progressively pivot and compromise more powerful accounts, ultimately achieving root access on cluster master nodes and leading to a full cluster takeover," the report said.
"Vulnerabilities offering a path for a low privileged user to fully take over an environment needs to be patched in the form of an incident response cycle, seeking to prove that the environment was not already compromised," Trey Ford, chief strategy and trust officer at crowdsourced security company Bugcrow said in an email to The Register.
In other words: "Assume breach," Ford added.
"The administrators managing OpenShift AI infrastructure need to patch this with a sense of urgency - this is a delightful vulnerability pattern for attackers looking to acquire both access and data," he said. "Security teams must move with a sense of purpose, both verifying that these environments have been patched, then investigating to confirm whether-and-if their clusters have been compromised."
