Read Time:4 Second
SentinelOne described some of ransomware groups’ favorite techniques for targeting cloud services
Yearly Archives: 2024
O2’s AI Granny Outsmarts Scam Callers with Knitting Tales
Safeguarding Healthcare Organizations from IoMT Risks
Read Time:8 Minute, 16 Second
The healthcare industry has undergone significant transformation with the emergence of the Internet of Medical Things (IoMT) devices. These devices ranging from wearable monitors to network imaging systems collect and process vast amounts of sensitive medical data based on which they make critical decisions about patients’ health. But at the same time, they also raise serious privacy and security concerns.
Cybercriminals often target vulnerabilities within these devices to gain entry into the hospital network and compromise healthcare data. Attacks on these interconnected devices cause life-threatening harm to patients, disrupt services, and bring financial and reputational costs to medical centers.
As hackers increasingly target IoMT devices and present significant threats to medical organizations, it is crucial to combat these risks and ensure patient safety.
Current Security Landscape of Medical Connected Devices
The global healthcare medical device market is expected to reach $332.67 billion by 2027. The acceleration in IoMT adoption shows that the healthcare industry found this technology useful. However, this innovation also carries possible threats and challenges. Below is an insight into the key security challenges that these IoT devices come with:
Ransomware Attacks
Cybercriminals often target medical devices and networks to access sensitive information like protected health information (PHI) and electronic health records (EHR). They even steal this information to put it up for sale on the dark web and, in return, demand hefty ransom.
For instance, in the crippling ransomware attack against Change Healthcare, the criminal gang ALPHV/Blackcat stole 4TB of patients’ records and affected one-third of people living in the USA. The stolen data was up for sale on the black market until hackers received $22 million as a ransom payment. Such incidents erode patients’ trust and cause healthcare organizations to face HIPAA violations ranging from $100 to $50,000 per violation.
Vulnerabilities Exploitation
Medical devices such as infusion pumps or pacemakers are not designed with security in mind. As a result, they may come with security vulnerabilities that hackers can exploit to get unauthorized access to medical data. For example, the Nozomi Network Lab found several security flaws within the GE Healthcare Vivid Ultrasound family that hackers can exploit to launch ransomware attacks and manipulate patients’ data.
Previously, the Palo Alto Network discovered 40 vulnerabilities and more than 70 security alerts in infusion pumps, putting them at risk of leaking sensitive information. Similarly, McAfee researchers identified significant vulnerabilities in two types of B.Braun infusion pumps that could enable hackers to deliver a lethal dosage of medications to suspected patients. Although no affected case was reported, this event highlighted the gaps in medical device security and the need for improvement.
Outdated and Unpatched Medical Devices
Outdated systems remain a top challenge for medical IoT as healthcare organizations continue to rely on legacy systems. Many of these devices aren’t designed with security in mind and stay in use for years and even decades.
The device manufacturers are reluctant to upgrade the system software because it’s expensive. This increases the risk of security flaws remaining undiscovered and unpatched, making the device more prone to cyber-attacks. These outdated devices serve as an entry point for hackers to access patients’ data and disrupt healthcare operations.
High-Risk Devices
The FBI cyber division has warned that the average healthcare device has 6.2 vulnerabilities, and 53% have active critical vulnerabilities. Unfortunately, the security teams can only address 5-20% of known vulnerabilities each month while new vulnerabilities are constantly added. This makes these devices highly valuable to hackers.
Forescout Research, in its Riskiest Connected Devices in 2024, named the five riskiest IoMT devices in 2024. This includes:
Medical information systems
Electrocardiograph machines
DICOM workstations
Picture archiving and communication systems (PACS)
Medication-dispensing systems
Researchers have warned that these devices could pose enormous risks to patient lives and personal information. For instance, the report found that DICOM and PACS are used in medical imaging, often run on legacy IT operating systems, and are unencrypted. This could allow attackers to tamper with medical images and even spread malware.
Supply Chain Issues
Hackers can exploit flaws in the supply chain mainly through exploiting unpatched vulnerabilities to disrupt healthcare operations and patient care. One example is the cyber attack on Swedish software firm Ortivus, which impacted at least two ambulance services across the UK without access to electronic patient records. The incident highlighted the flaws in supply chain security and required healthcare providers to ensure that their vendors are secure and resilient against such attacks.
The Future of Medical IoT Security
Investing in emerging technologies like blockchain technology and zero-trust framework can enhance healthcare organizations’ security posture. These technologies have advanced ability to detect risks within medical devices, prevent unauthorized access, and ensure compliance.
Embracing Blockchain Technology
Blockchain technology plays a vital role in securing patient health records and ensuring privacy. It offers a secure and decentralized platform where each block links to the previous one, ensuring the information remains unchanged for storing sensitive healthcare data. By encrypting and distributing the data across the healthcare network, blockchain ensures that records are accessible to only authorized parties. This reduces the risk of data breaches, improves patients’ trust, and helps comply with regulations like HIPAA.
The security and transparency provided by blockchain technology is an ideal structure for transmitting Electronic Health Records (EHRs) and other medical data among connected devices. Blockchain’s cryptographic protections make transfers more secure than conventional encryption, preventing tampering and risk of data breaches. This also ensures that healthcare professionals can access updated patient information, which improves diagnosis and reduces the risk of errors.
Healthcare organizations might use blockchain technology to optimize the IoT supply chain, providing end-to-end traceability and visibility. Blockchain records each step of the supply chain from manufacturing to delivery and ensures that medical supplies are authentic. This tracking allows healthcare professionals to verify where their IoMT endpoints come from. They could then hold third-party providers to higher standards, ensure they only use secure devices, and prevent supply chain attacks.
However, medical organizations incorporating blockchain systems must consider the limitations it poses. Blockchains consume considerable energy, which can be an issue for facilities with limited hardware. Medical centers must review their network resources before implementing blockchain technology. Also, it’d be best to consult blockchain experts to ensure these networks won’t consume much of the system’s capacity.
Implementing Zero-Trust Framework
Zero Trust has emerged as a great security strategy that prevents unauthorized access to healthcare data. This security framework requires both internal and external users to authenticate, authorize, and verify for security configuration and posture before getting access to apps and data.
Network segmentation is an integral principle of ZTNA that improves IoMT security by categorizing devices based on their risk level, function, and data sensitivity. For instance, it isolates critical medical devices from less critical ones, preventing lateral movement by attackers and the impact of a potential breach.
The ZTNA approach also adheres to the principle of least privilege, restricting the access rights of users and devices to the minimum privilege to perform their tasks. By enforcing access control policies, ZTNA limits the opportunities for hackers to exploit vulnerable IoT devices and thus reduces the attack surface.
Apart from this, the zero-trust framework allows medical professionals to identify and gain visibility into what devices are connected to their networks and the resources they access. It involves real-time tracking and behavioral analysis of medical devices, triggering alerts for deviations from typical patterns. It then notifies the security teams to respond to threats promptly. This way, ZTNA limits network traffic for unauthorized devices and maintains a secure IoT environment.
On the downside, ZTNA implementation may cause significant costs, posing challenges for organizations with limited budgets. Once implemented, medical professionals must also continuously verify their identity to access data or communicate with patients. Professionals familiar with the traditional security model find it frustrating and affecting productivity, so they resist transitioning to ZTNA. By running zero-trust trials and training employees about the value of ZTNA, healthcare organizations can overcome these challenges.
The Need for Advanced Measures to Boost IoMT Security
Healthcare organizations must take proactive steps to protect interconnected medical devices from potential risks. Here are some measures security teams should take to reduce their exposure and create a safe place for patients and staff:
Evaluate the security measures implemented by medical IoT device vendors. The vendor assessment activities include checking access controls, encryption, software patching, and vulnerability management processes to ensure visibility and help mitigate potential risks.
Utilize healthcare phone systems so healthcare organizations can focus on critical security measures while ensuring secure communication between medical devices and efficiently managing patient inquiries.
Security teams must follow industry standard guidelines for medical devices described by FDA, NIST, IMDRF, and ISO. These initiatives establish cybersecurity principles and technical standards to guide healthcare providers and manufacturers in addressing security risks.
Manufacturers should consistently release software updates, firmware, and patches. The security teams must promptly apply the patches and updates to protect against known threats or new vulnerabilities.
Security awareness training should be an ongoing process instead of a one-time event. Healthcare professionals should receive regular training as this empowers them to detect, respond, and mitigate security threats effectively.
Conduct a comprehensive risk assessment for each connected medical device to identify vulnerabilities and potential weak points. Categorize threats by severity and implement immediate actions to address high-risk issues.
Final Thoughts
The Internet of Medical Things (IoMT) is an intuitive innovation within the healthcare industry that aims to revolutionize patient care and healthcare management. With these devices, medical professionals can streamline healthcare processes and improve the quality of patient care.
As the reliance on medical devices is full of security and privacy risks, medical organizations must stay informed about the latest threats and practice security measures to address these issues. Implementing ZTNA and blockchain technology helps mitigate risks and ensures the safety and security of healthcare data.
An Interview With the Target & Home Depot Hacker
Read Time:7 Minute, 27 Second
In December 2023, KrebsOnSecurity revealed the real-life identity of Rescator, the nickname used by a Russian cybercriminal who sold more than 100 million payment cards stolen from Target and Home Depot between 2013 and 2014. Moscow resident Mikhail Shefel, who confirmed using the Rescator identity in a recent interview, also admitted reaching out because he is broke and seeking publicity for several new money making schemes.
Mikhail “Mike” Shefel’s former Facebook profile. Shefel has since legally changed his last name to Lenin.
Mr. Shefel, who recently changed his legal surname to Lenin, was the star of last year’s story, Ten Years Later, New Clues in the Target Breach. That investigation detailed how the 38-year-old Shefel adopted the nickname Rescator while working as vice president of payments at ChronoPay, a Russian financial company that paid spammers to advertise fake antivirus scams, male enhancement drugs and knockoff pharmaceuticals.
Mr. Shefel did not respond to requests for comment in advance of that December 2023 profile. Nor did he respond to reporting here in January 2024 that he ran an IT company with a 34-year-old Russian man named Aleksandr Ermakov, who was sanctioned by authorities in Australia, the U.K. and U.S. for stealing data on nearly 10 million customers of the Australian health insurance giant Medibank.
But not long after KrebsOnSecurity reported in April that Shefel/Rescator also was behind the theft of Social Security and tax information from a majority of South Carolina residents in 2012, Mr. Shefel began contacting this author with the pretense of setting the record straight on his alleged criminal hacking activities.
In a series of live video chats and text messages, Mr. Shefel confirmed he indeed went by the Rescator identity for several years, and that he did operate a slew of websites between 2013 and 2015 that sold payment card data stolen from Target, Home Depot and a number of other nationwide retail chains.
Shefel claims the true mastermind behind the Target and other retail breaches was Dmitri Golubov, an infamous Ukrainian hacker known as the co-founder of Carderplanet, among the earliest Russian-language cybercrime forums focused on payment card fraud. Mr. Golubov could not be reached for comment, and Shefel says he no longer has the laptop containing evidence to support that claim.
Shefel asserts he and his team were responsible for developing the card-stealing malware that Golubov’s hackers installed on Target and Home Depot payment terminals, and that at the time he was technical director of a long-running Russian cybercrime community called Lampeduza.
“My nickname was MikeMike, and I worked with Dmitri Golubov and made technologies for him,” Shefel said. “I’m also godfather of his second son.”
Dmitri Golubov, circa 2005. Image: U.S. Postal Investigative Service.
A week after breaking the story about the 2013 data breach at Target, KrebsOnSecurity published Who’s Selling Cards from Target?, which identified a Ukrainian man who went by the nickname Helkern as Rescator’s original identity. But Shefel claims Helkern was subordinate to Golubov, and that he was responsible for introducing the two men more than a decade ago.
“Helkern was my friend, I [set up a] meeting with Golubov and him in 2013,” Shefel said. “That was in Odessa, Ukraine. I was often in that city, and [it’s where] I met my second wife.”
Shefel claims he made several hundred thousand dollars selling cards stolen by Golubov’s Ukraine-based hacking crew, but that not long after Russia annexed Crimea in 2014 Golubov cut him out of the business and replaced Shefel’s malware coding team with programmers in Ukraine.
Golubov was arrested in Ukraine in 2005 as part of a joint investigation with multiple U.S. federal law enforcement agencies, but his political connections in the country ensured his case went nowhere. Golubov later earned immunity from prosecution by becoming an elected politician and founding the Internet Party of Ukraine, which called for free internet for all, the creation of country-wide “hacker schools” and the “computerization of the entire economy.”
Mr. Shefel says he stopped selling stolen payment cards after being pushed out of the business, and invested his earnings in a now-defunct Russian search engine called tf[.]org. He also apparently ran a business called click2dad[.]net that paid people to click on ads for Russian government employment opportunities.
When those enterprises fizzled out, Shefel reverted to selling malware coding services for hire under the nickname “Getsend“; this claim checks out, as Getsend for many years advertised the same Telegram handle that Shefel used in our recent chats and video calls.
A screenshot of a Telegram conversation with Mikhail Shefel/Lenin.
Shefel acknowledged that his outreach was motivated by a desire to publicize several new business ventures. None of those will be mentioned here because Shefel is already using my December 2023 profile of him to advertise what appears to be a pyramid scheme, and to remind others within the Russian hacker community of his skills and accomplishments.
Shefel says he is now flat broke, and that he currently has little to show for a storied hacking career. The Moscow native said he recently heard from his ex-wife, who had read last year’s story about him and was suddenly wondering where he’d hidden all of his earnings.
More urgently, Shefel needs money to stay out of prison. In February, he and Ermakov were arrested on charges of operating a short-lived ransomware affiliate program in 2021 called Sugar (a.k.a. Sugar Locker), which targeted single computers and end-users instead of corporations. Shefel is due to face those charges in a Moscow court on Friday, Nov. 15, 2024. Ermakov was recently found guilty and given two years probation.
Shefel claims his Sugar ransomware affiliate program was a bust, and never generated any profits. Russia is known for not prosecuting criminal hackers within its borders who scrupulously avoid attacking Russian businesses and consumers. When asked why he now faces prosecution over Sugar, Shefel said he’s certain the investigation was instigated by Pyotr “Peter” Vrublevsky — the son of his former boss at ChronoPay.
ChronoPay founder and CEO Pavel Vrublevsky was the key subject of my 2014 book Spam Nation, which described his role as head of one of Russia’s most notorious criminal spam operations.
Vrublevsky Sr. recently declared bankruptcy, and is currently in prison on fraud charges. Russian authorities allege Vrublevsky operated several fraudulent SMS-based payment schemes. They also accused Vrublevsky of facilitating money laundering for Hydra, the largest Russian darknet market at the time. Hydra trafficked in illegal drugs and financial services, including cryptocurrency tumbling for money laundering, exchange services between cryptocurrency and Russian rubles, and the sale of falsified documents and hacking services.
However, in 2022 KrebsOnSecurity reported on a more likely reason for Vrublevsky’s latest criminal charges: He’d been extensively documenting the nicknames, real names and criminal exploits of Russian hackers who worked with the protection of corrupt officials in the Russian Federal Security Service (FSB), and operating a Telegram channel that threatened to expose alleged nefarious dealings by Russian financial executives.
Shefel believes Vrublevsky’s son Peter paid corrupt cops to levy criminal charges against him after reporting the youth to Moscow police, allegedly for walking around in public with a loaded firearm. Shefel says the Russian authorities told the younger Vrublevsky that he had lodged the firearms complaint.
In July 2024, the Russian news outlet Izvestia published a lengthy investigation into Peter Vrublevsky, alleging that the younger son took up his father’s mantle and was responsible for advertising Sprut, a Russian-language narcotics bazaar that sprang to life after the Hydra darknet market was shut down by international law enforcement agencies in 2022.
Izvestia reports that Peter Vrublevsky was the advertising mastermind behind this 3D ad campaign and others promoting the Russian online narcotics bazaar Sprut.
Izvestia reports that Peter Vrublevsky is currently living in Switzerland, where he reportedly fled in 2022 after being “arrested in absentia” in Russia on charges of running a violent group that could be hired via Telegram to conduct a range of physical attacks in real life, including firebombings and muggings.
Shefel claims his former partner Golubov was involved in the development and dissemination of early ransomware strains, including Cryptolocker, and that Golubov remains active in the cybercrime community.
Meanwhile, Mr. Shefel portrays himself as someone who is barely scraping by with the few odd coding jobs that come his way each month. Incredibly, the day after our initial interview via Telegram, Shefel proposed going into business together.
By way of example, he suggested maybe a company centered around recovering lost passwords for cryptocurrency accounts, or perhaps a series of online retail stores that sold cheap Chinese goods at a steep markup in the United States.
“Hi, how are you?” he inquired. “Maybe we can open business?”
USN-7112-1: GD Graphics Library vulnerability
Read Time:14 Second
It was discovered that the GD Graphics Library did not perform proper
bounds checking while handling BMP and WebP files. If a user were tricked
into opening a specially crafted file, an attacker could possibly use
this issue to cause a denial of service (application crash).
DSA-5812-1 postgresql-15 – security update
Read Time:9 Second
Multiple security issues were discovered in PostgreSQL, which may result in
the execution of arbitrary code, privilege escalation or log manipulation.
DSA-5813-1 symfony – security update
Read Time:9 Second
Moritz Rauch discovered that the Symfony PHP framework implemented
persisted remember-me cookies incorrectly, which could result in
authentication bypass.
DSA-5814-1 thunderbird – security update
Read Time:8 Second
A security issue was discovered in Thunderbird, which could result in
the disclosure of OpenPGP encrypted messages.
USN-7111-1: Go vulnerabilities
Read Time:2 Minute, 43 Second
Philippe Antoine discovered that Go incorrectly handled crafted HTTP/2
streams. An attacker could possibly use this issue to cause a denial of
service. (CVE-2022-41723)
Marten Seemann discovered that Go did not properly manage memory under
certain circumstances. An attacker could possibly use this issue to cause
a panic resulting in a denial of service. (CVE-2022-41724)
Ameya Darshan and Jakob Ackermann discovered that Go did not properly
validate the amount of memory and disk files ReadForm can consume. An
attacker could possibly use this issue to cause a panic resulting in a
denial of service. (CVE-2022-41725)
Jakob Ackermann discovered that Go incorrectly handled multipart
forms. An attacker could possibly use this issue to consume an excessive
amount of resources, resulting in a denial of service. (CVE-2023-24536)
It was discovered that Go did not properly validate the “//go:cgo_”
directives during compilation. An attacker could possibly use this issue
to inject arbitrary code during compile time. (CVE-2023-39323)
Bartek Nowotarski was discovered that the Go net/http module did not
properly handle the requests when request’s headers exceed MaxHeaderBytes.
An attacker could possibly use this issue to cause a panic resulting into
a denial of service. (CVE-2023-45288)
Bartek Nowotarski discovered that the Go net/http module did not properly
validate the total size of the parsed form when parsing a multipart form.
An attacker could possibly use this issue to cause a panic resulting into a
denial of service. (CVE-2023-45290)
John Howard discovered that the Go crypto/x509 module did not properly
handle a certificate chain which contains a certificate with an unknown
public key algorithm. An attacker could possibly use this issue to cause
a panic resulting into a denial of service. (CVE-2024-24783)
Juho Nurminen discovered that the Go net/mail module did not properly
handle comments within display names in the ParseAddressList function.
An attacker could possibly use this issue to cause a panic resulting into
a denial of service. (CVE-2024-24784)
Yufan You discovered that the Go archive/zip module did not properly
handle certain types of invalid zip files differs from the behavior of
most zip implementations. An attacker could possibly use this issue to
cause a panic resulting into a denial of service. (CVE-2024-24789)
Geoff Franks discovered that the Go net/http module did not properly
handle responses to requests with an “Expect: 100-continue” header under
certain circumstances. An attacker could possibly use this issue to
cause a denial of service. (CVE-2024-24791)
It was discovered that the Go parser module did not properly handle deeply
nested literal values. An attacker could possibly use this issue to cause
a panic resulting in a denial of service. (CVE-2024-34155)
Md Sakib Anwar discovered that the Go encoding/gob module did not properly
handle message decoding under certain circumstances. An attacker could
possibly use this issue to cause a panic resulting in a denial of service.
(CVE-2024-34156)
It was discovered that the Go build module did not properly handle certain
build tag lines with deeply nested expressions. An attacker could possibly
use this issue to cause a panic resulting in a denial of service.
(CVE-2024-34158)
USN-7088-5: Linux kernel vulnerabilities
Read Time:3 Minute, 56 Second
Ziming Zhang discovered that the VMware Virtual GPU DRM driver in the
Linux kernel contained an integer overflow vulnerability. A local
attacker could use this to cause a denial of service (system crash).
(CVE-2022-36402)
Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
– ARM64 architecture;
– PowerPC architecture;
– User-Mode Linux (UML);
– x86 architecture;
– Block layer subsystem;
– Cryptographic API;
– Android drivers;
– Serial ATA and Parallel ATA drivers;
– ATM drivers;
– Drivers core;
– CPU frequency scaling framework;
– Device frequency scaling framework;
– GPU drivers;
– HID subsystem;
– Hardware monitoring drivers;
– InfiniBand drivers;
– Input Device core drivers;
– Input Device (Miscellaneous) drivers;
– IOMMU subsystem;
– IRQ chip drivers;
– ISDN/mISDN subsystem;
– LED subsystem;
– Multiple devices driver;
– Media drivers;
– EEPROM drivers;
– VMware VMCI Driver;
– MMC subsystem;
– Network drivers;
– Near Field Communication (NFC) drivers;
– NVME drivers;
– Device tree and open firmware driver;
– Parport drivers;
– PCI subsystem;
– Pin controllers subsystem;
– Remote Processor subsystem;
– S/390 drivers;
– SCSI drivers;
– QCOM SoC drivers;
– Direct Digital Synthesis drivers;
– TTY drivers;
– Userspace I/O drivers;
– DesignWare USB3 driver;
– USB Gadget drivers;
– USB Host Controller drivers;
– USB Serial drivers;
– USB Type-C Connector System Software Interface driver;
– USB over IP driver;
– BTRFS file system;
– File systems infrastructure;
– Ext4 file system;
– F2FS file system;
– JFS file system;
– NILFS2 file system;
– BPF subsystem;
– Core kernel;
– DMA mapping infrastructure;
– Tracing infrastructure;
– Radix Tree data structure library;
– Kernel userspace event delivery library;
– Objagg library;
– Memory management;
– Amateur Radio drivers;
– Bluetooth subsystem;
– CAN network layer;
– Networking core;
– Ethtool driver;
– IPv4 networking;
– IPv6 networking;
– IUCV driver;
– KCM (Kernel Connection Multiplexor) sockets driver;
– MAC80211 subsystem;
– Netfilter;
– Network traffic control;
– SCTP protocol;
– Sun RPC protocol;
– TIPC protocol;
– TLS protocol;
– Wireless networking;
– AppArmor security module;
– Simplified Mandatory Access Control Kernel framework;
– SoC audio core drivers;
– USB sound devices;
(CVE-2024-42289, CVE-2024-26640, CVE-2024-42246, CVE-2024-43914,
CVE-2024-46744, CVE-2024-45026, CVE-2024-41071, CVE-2024-43893,
CVE-2024-46689, CVE-2024-41073, CVE-2024-42292, CVE-2024-43884,
CVE-2024-42301, CVE-2024-43856, CVE-2024-46756, CVE-2024-46759,
CVE-2024-27051, CVE-2024-26668, CVE-2024-46840, CVE-2024-42306,
CVE-2024-41042, CVE-2024-45006, CVE-2024-42309, CVE-2024-26891,
CVE-2024-42283, CVE-2024-46782, CVE-2024-44948, CVE-2024-43839,
CVE-2024-47667, CVE-2024-44965, CVE-2024-42284, CVE-2024-44987,
CVE-2024-46777, CVE-2024-41017, CVE-2024-46722, CVE-2024-41015,
CVE-2024-46817, CVE-2024-46740, CVE-2024-43894, CVE-2024-26800,
CVE-2024-45003, CVE-2024-46822, CVE-2024-26641, CVE-2024-44960,
CVE-2024-44935, CVE-2024-42229, CVE-2024-42285, CVE-2024-44988,
CVE-2024-46829, CVE-2024-41012, CVE-2024-46750, CVE-2024-43835,
CVE-2024-43883, CVE-2024-43882, CVE-2024-46844, CVE-2024-41011,
CVE-2024-44999, CVE-2024-46757, CVE-2024-42131, CVE-2024-46714,
CVE-2024-41081, CVE-2024-45021, CVE-2024-46747, CVE-2024-46673,
CVE-2024-46737, CVE-2024-43841, CVE-2024-42304, CVE-2024-45008,
CVE-2024-42259, CVE-2024-42276, CVE-2024-46685, CVE-2024-46743,
CVE-2023-52614, CVE-2024-42313, CVE-2024-41090, CVE-2024-46677,
CVE-2024-43861, CVE-2024-42288, CVE-2024-43890, CVE-2024-41063,
CVE-2024-43860, CVE-2024-47669, CVE-2024-42305, CVE-2024-43879,
CVE-2024-42281, CVE-2024-46798, CVE-2024-42280, CVE-2024-42297,
CVE-2024-42310, CVE-2024-44947, CVE-2024-40929, CVE-2024-41068,
CVE-2024-42244, CVE-2024-41059, CVE-2024-47659, CVE-2024-43858,
CVE-2024-41020, CVE-2024-41064, CVE-2023-52531, CVE-2024-41022,
CVE-2024-46723, CVE-2024-42311, CVE-2024-44969, CVE-2024-45025,
CVE-2024-44946, CVE-2024-46755, CVE-2024-46815, CVE-2024-46761,
CVE-2024-43867, CVE-2024-41070, CVE-2024-43880, CVE-2024-47663,
CVE-2024-44944, CVE-2024-45028, CVE-2024-43908, CVE-2024-46783,
CVE-2024-43853, CVE-2024-41091, CVE-2024-46719, CVE-2024-43871,
CVE-2024-36484, CVE-2024-46771, CVE-2024-42265, CVE-2024-42286,
CVE-2024-43854, CVE-2024-41072, CVE-2024-43830, CVE-2024-46721,
CVE-2024-44995, CVE-2024-46828, CVE-2024-46780, CVE-2024-46739,
CVE-2024-46676, CVE-2024-47668, CVE-2024-42287, CVE-2023-52918,
CVE-2024-46745, CVE-2024-35848, CVE-2024-42290, CVE-2024-41065,
CVE-2024-42271, CVE-2024-38611, CVE-2024-41098, CVE-2024-43846,
CVE-2024-26885, CVE-2021-47212, CVE-2024-46781, CVE-2024-26607,
CVE-2024-26669, CVE-2024-44954, CVE-2024-42295, CVE-2024-46818,
CVE-2024-44952, CVE-2024-46738, CVE-2024-44998, CVE-2024-46675,
CVE-2024-43829, CVE-2024-46758, CVE-2024-38602, CVE-2024-46800,
CVE-2024-46679)