VulnCon 2025, EU CRA, CVE funding, Smishing Kit
Notable security news for the week of April 13th through April 20th. Your editor this week is Chris from the F5 Security Incident Response Team. A bit of a different format this week as I was in Raleigh for VulnCon 2025 the previous week. I will discuss highlights from that as well as notable events from the past week.
VulnCon 2025
The 2025 Vulnerability Management Ecosystem Collaboration, Ideation, and Action Conference (aka “VulnCon”), which was sponsored by FIRST and the CVE Program, was held from April 7th through April 10th this year. The aim of this conference is to promote collaboration between various vulnerability management and cybersecurity professionals to better help the whole cybersecurity ecosystem. Key topics that were highlighted this year were the EU's Cyber Resilience Act (CRA), Vulnerability Exploitability eXchange (VEX), Cybersecurity Assurance Framework (CSAF), and publishing more complete CVE records or Vulnrichment. I will discuss the CRA in the next paragraph. VEX facilitates the exchange of vulnerability information, fostering collaboration to swiftly address emerging threats. Concurrently, CSAF ensures a standardized approach to cybersecurity practices. One of the pushes that was discussed was to get security scanners to start ingesting VEX to help decrease the amount of false positives and focus more on vulnerabilities that are exploitable. As for Vulnrichment, it is alarming that a large number of CVEs that are disclosed every year do not include Common Weakness Enumerations (CWE) or Common Vulnerability Scoring System (CVSS) scores. I agree that adding this information at a minimum would be very beneficial to both the consumers as well as the vendor. The vendor is in the best position to assign these in a more accurate manner since they are most familiar with the products.
https://www.first.org/conference/vulncon2025/
https://openssf.org/blog/2023/09/07/vdr-vex-openvex-and-csaf/
EU Cyber Resilience Act (CRA)
The Cyber Resilience Act introduces mandatory cybersecurity requirements for hardware and software products, throughout their whole lifecycle. The main goals of this act are to ensure that products with digital elements placed on the EU market have fewer vulnerabilities that
Manufacturers remain responsible for cybersecurity throughout a product’s life cycle, improve transparency on security of hardware and software products and bring benefits to business users and consumers from better protection. Products will bear the CE marking as is common with many other products sold, which means they have been assessed to meet high safety, health, and environmental protection requirements.
The three main roles that are laid out are:
- Manufacturers: If you develop or manufacture products with "digital elements" for sale in the EU.
- Open-Source Software (OSS) Stewards: Entity other than a manufacturer that provides support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products. Examples of this would be the Linux Foundation, Apache Foundation, etc....
- OSS Developers: Upstream maintainer or developer of open-source software that is used by the manufacturer.
The key point to note in this distinction of these three roles is that if there is a vulnerability exploited in open-source software, the manufacturer is the one held liable. The OSS Steward and the OSS Developers are not being held liable. This makes it a good idea to develop working relationships with the OSS upstream developers for when emergencies do arise. Now to focus on the manufacturer requirements. I will not touch all of them as the CRA is a large document but will point out some of the key topics. Secure-By-Default and Secure-By-Design principles will now be a requirement and not just a pledge. Products with digital elements shall be delivered without any known exploitable vulnerabilities. Manufacturers will need to provide evidence that the product was checked before release. A risk assessment will need to be provided with the product and the contents of that assessment are laid out in Annex I of the document. Manufactures must be able to provide SBOMS in either SPDX or CycloneDX format at the request of authorities. Manufacturers must , address and remediate vulnerabilities without delay, which includes providing security updates. Manufacturers must provide support for a minimum of 5 years, including security updates and that each security update remains available after it has been issued for a minimum of 10 years or for the remainder of the support period, whichever is longer.
There are also reporting requirements. Highlight a couple of them; they pertain to actively exploited vulnerabilities and severe incidents having an impact on the security of the product. An early warning notification of an actively exploited vulnerability or severe incident, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it. Then "an incident notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the incident, which shall provide general information, where available, about the nature of the incident, an initial assessment of the incident, as well as any corrective or mitigating measures taken, and corrective or mitigating measures that users can take, and which shall also indicate, where applicable, how sensitive the manufacturer considers the notified information to be". That was taken from the document and you can see how thorough they are being when detailing what to report. The final report will need to be submitted by 14 days for active exploits and one month for severe incidents. Then to explain where to report: "The notification shall be submitted using the electronic notification end-point of the CSIRT designated as coordinator of the Member State where the manufacturers have their main establishment in the Union and shall be simultaneously accessible to ENISA". This means that the manufacturer will need to choose one of the European country's CSIRT teams to be the point of contact.
As for the consequences of non-compliance, the EU is not playing around with that either:
- Non-compliance with the essential cybersecurity requirements set out in Annex I and the obligations set out in Articles 13 and 14 shall be subject to administrative fines of up to EUR 15,000,000 or, if the offender is an undertaking, up to 2.5% of its total worldwide annual turnover for the preceding financial year, whichever is higher.
- Non-compliance with the obligations set out in Articles 18 to 23, Article 28, Article 30(1) to (4), Article 31(1) to (4), Article 32(1), (2) and (3), Article 33(5), and Articles 39, 41, 47, 49 and 53 shall be subject to administrative fines of up to EUR 10,000,000 or, if the offender is an undertaking, up to 2% of its total worldwide annual turnover for the preceding financial year, whichever is higher.
- The supply of incorrect, incomplete or misleading information to notified bodies and market surveillance authorities in reply to a request shall be subject to administrative fines of up to EUR 5,000,000 or, if the offender is an undertaking, up to 1% of its total worldwide annual turnover for the preceding financial year, whichever is higher.
To explain those bullet points more simply, everything I mentioned above about manufacturer requirements and reporting all fall under Annex I or Articles 13 and 14 so would be subject to the most severe penalties per incident.
As for the timelines of this act, the CRA was officially adopted on October 10, 2024, and entered into force on December 10, 2024. However, the CRA's main obligations will apply starting from December 11, 2027. Some earlier obligations will apply, such as the reporting of vulnerabilities and severe incidents, starting from September 11, 2026. Additionally, the rules on conformity assessment bodies will be applicable from June 11, 2026.
https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
https://github.com/SecurityCRob/presentations/blob/main/CRA%20PSIRT%20TL_DR.pdf
CVE Program Funding
The Common Vulnerabilities and Exposures (CVE) program, managed by MITRE, was facing funding expiration on April 16, 2025. The program is essential for identifying and tracking security vulnerabilities in software and hardware. Without funding, the CVE program would stop adding new vulnerabilities, which could lead to significant impacts on national vulnerability databases, cybersecurity tools, incident response operations, and critical infrastructure. MITRE's Vice President Yosry Barsoum expressed hope that the government is making efforts to continue supporting the program. Luckily, the Department of Homeland Security's (DHS) Cybersecurity & Infrastructure Security Agency (CISA) was able to secure funding at the last moment, to fund the program for 11 more months. This is despite ongoing budget and staffing cuts to CISA by the current administration.
The cybersecurity community has expressed concern over the potential loss of the CVE program, emphasizing its importance in standardizing vulnerability information and aiding in the timely patching of security flaws. On April 16, MITRE announced the creation of a non-profit entity called "The CVE Foundation" to continue the program's work under a new funding mechanism.
https://krebsonsecurity.com/2025/04/funding-expires-for-key-cyber-vulnerability-database/
The CVE Foundation
The CVE Foundation was launched to secure the future of the CVE Program. The CVE Foundation was formally established on April 16, 2025, to ensure the long-term viability, stability, and independence of the Common Vulnerabilities and Exposures (CVE) Program. The CVE Program has been a U.S. government-funded initiative for 25 years, raising concerns about sustainability and neutrality due to its reliance on a single government sponsor. MITRE notified the CVE Board on April 15, 2025, that the U.S. government would not renew its contract for managing the program. In response, a coalition of CVE Board members developed a strategy to transition CVE to a dedicated, non-profit foundation to continue delivering high-quality vulnerability identification. CVE identifiers and data are crucial for cybersecurity professionals worldwide, aiding in security tools, advisories, threat intelligence, and response. Going forward, the CVE Foundation aims to eliminate a single point of failure in the vulnerability management ecosystem and ensure the CVE Program remains globally trusted and community-driven.
https://www.thecvefoundation.org/home
Pay Your Tolls!!
About 3 and a half years ago, I was driving into Denver on Interstate 70 coming from the East. I had no need to drive through Denver as I was heading north through Wyoming anyway. Well, a few miles before the city there was an offramp for E-470, a toll highway that would bypass Denver and connect to I-25 a few miles north of the city. I had never used a toll highway before since I live in Eastern Washington where they are unheard of. I was picturing a scene out of a movie where you pull up to a booth and pay an attendant. I was surprised as I merged onto the highway and everyone was driving at 60+ MPH. I saw a sign that stated the system used E-ZPass and would scan the license plate. Fast forward a few months and I receive a bill in the mail from E-ZPass, a pretty nice way to bypass driving through the middle of a large city, I thought.
Now, unfortunately, a smishing campaign is targeting that same system to trick victims into giving them their payment information. Since mid-October 2024, multiple financially motivated threat actors have been using a smishing kit developed by "Wang Duo Yu" to target toll road users in eight U.S. states. The campaign impersonates U.S. electronic toll collection systems like E-ZPass, sending SMS messages and Apple iMessages about unpaid tolls, urging recipients to click on fake links. Victims are prompted to solve a fake CAPTCHA challenge and enter personal and financial information on fraudulent pages, which is then siphoned off to the threat actors. Wang Duo Yu, a computer science student in China, is alleged to be the creator of the phishing kits used by the Smishing Triad, a Chinese organized cybercrime group. The Smishing Triad has conducted large-scale smishing attacks targeting postal services in 121 countries, using failed package delivery lures to harvest personal and financial information. Services like Oak Tel facilitate smishing on a global scale, allowing cybercriminals to send bulk SMS and manage campaigns efficiently.
I have personally received 2 or 3 of these over the past few months. Luckily, I know the one time I drove on a toll road, so it was obvious to me that this was fake. I worry about people that are using these systems more regularly that may fall victim.
https://thehackernews.com/2025/04/chinese-smishing-kit-behind-widespread.html
