Aggregator

A vulnerability categorized as critical has been discovered in Quest KACE SMA up to 14.1. This vulnerability affects unknown code of the component Backup Handler. The manipulation results in improper verification of cryptographic signature. This vulnerability is cataloged as CVE-2025-32977. The attack may be launched remotely. There is no exploit available. It is advisable to upgrade the affected component.

A vulnerability, which was classified as problematic, was found in SAP NetWeaver Application Server ABAP up to 816. Affected by this issue is some unknown functionality. Executing a manipulation can lead to open redirect. This vulnerability is handled as CVE-2026-34257. The attack can be executed remotely. There is not any exploit available. A patch should be applied to remediate this issue.

A vulnerability was found in Google Android 10.0/11.0/12.0/13.0 and classified as problematic. This impacts the function NotificationChannel of the file NotificationChannel.java. Such manipulation leads to resource consumption. This vulnerability is documented as CVE-2022-20486. The attack needs to be performed locally. There is not any exploit available. Applying a patch is advised to resolve this issue.

A vulnerability was found in Google Android 10.0/11.0/12.0/13.0. It has been classified as problematic. Affected is the function NotificationChannel of the file NotificationChannel.java. Performing a manipulation results in resource consumption. This vulnerability is reported as CVE-2022-20487. The attack requires a local approach. No exploit exists. It is suggested to install a patch to address this issue.

A vulnerability has been found in Google Android 10.0/11.0/12.0/13.0 and classified as problematic. This affects the function NotificationChannel of the file NotificationChannel.java. This manipulation causes resource consumption. This vulnerability is registered as CVE-2022-20485. The attack needs to be launched locally. No exploit is available. It is recommended to apply a patch to fix this issue.

The latest wave of "Operation PowerOFF," on April 13, 2026, targeted the distributed denial-of-service (DDoS) ecosystem and its users across 21 countries. [...]

Apr 16, 2026 - Alan Fagan - The EU AI Act cares about evidence, not intentWhen National Competent Authorities begin enforcement on August 2, 2026, they will ask organisations what AI systems they operate, how those systems are being used, and what controls are in place. Many organisations will struggle to answer these questions.The Shadow AI Problem is Bigger Than You ThinkWe have been here before. When cloud computing arrived, IT departments spent years chasing down unauthorised SaaS subscriptions, known as Shadow IT. Shadow AI is the same problem running at a dramatically higher speed.More than 80% of workers, including nearly 90% of security professionals, use unapproved AI tools in their jobs. The people responsible for enforcing your security policies are among the most likely to be circumventing them with AI tools you have never reviewed or approved.The channels are varied and often invisible to security teams:Browser extensions. A marketing employee installs an AI writing assistant. A lawyer uses a browser-based summarisation tool to review contracts. Neither is reviewed by legal or IT.Embedded features. Enterprise software vendors have rolled out AI features that activate without a separate purchase decision. Your existing vendor agreements may not adequately govern what those features do with your data.Developer shortcuts. Engineers use unapproved large language models to refactor code, write tests, or debug production issues. Proprietary source code and data enter third-party model APIs without any review of where that data goes or how it is stored.About 38% of employees share confidential data with AI platforms without approval. Every one of those interactions is a potential compliance issue under the EU AI Act.Why the Spreadsheet Audit FailsMost GRC teams begin their AI Act readiness work with what might be called a stock take. Department heads receive a survey and fill it in based on what they know about, or feel comfortable disclosing. The results get compiled into a spreadsheet. A compliance tick appears next to "AI Inventory."This approach has three fundamental problems under the EU AI Act.First, it captures a moment in time. AI adoption inside organisations moves faster than any quarterly audit cycle. A new tool can be adopted by an entire department in an afternoon. A CRM platform can enable a new AI feature overnight, rendering the inventory obsolete.Second, it relies on self-reporting from people who may not understand what they are using. A department head who approves an AI-assisted analytics tool may not know it routes queries through a third-party LLM, or that it qualifies as a high-risk system.Lastly, it creates a false sense of control. A documented inventory that misses 60% of actual AI usage is not an adequate compliance asset in a regulatory investigation.The High-Risk SystemThe EU AI Act classifies AI systems used for recruitment, employee evaluation, credit scoring, and access to essential services as high-risk under Annex III.In practice, this means if an employee in your HR team is using an AI tool to screen CVs or score candidates without formal approval, your organisation has deployed a high-risk AI system. You are subject to the obligations that come with that classification, even if you didn’t know about it.Article 12 states that deployers of high-risk systems must ensure those systems allow for the automatic recording of events throughout their lifetime, retained for a minimum of six months. You cannot log systems you have not discovered, or govern what you cannot see.Regulation RequirementsThe Act defines two primary roles. Providers, who develop and place AI systems on the market, and deployers, who use those systems in their own operations. Most European enterprises are deployers.Article 26 places ongoing monitoring obligations on deployers of high-risk AI systems. Article 9 requires a documented risk management system. Article 10 governs data quality and data governance. Together, these obligations require a technical foundation, not a document library.Under Article 99, non-compliance with high-risk AI system requirements can result in fines of up to €15 million or 3% of total worldwide annual turnover. For violations of Article 5's prohibited practices, that rises to €35 million or 7% of global turnover. The 15-Minute StandardThe question for every CISO and GRC leader is not whether they have completed an AI inventory, it’s whether their inventory is accurate, continuous, and audit-ready.FireTail takes a different approach. Rather than relying on surveys and spreadsheets, we deploy automated discovery across your entire environment, covering cloud infrastructure, browser-based activity, and application-level AI integrations. Within 15 minutes of deployment, you have a living, continuously updated inventory of every AI model, integration, service and prompt.This inventory is the foundation for everything else the EU AI Act requires: risk classification, logging, monitoring, and governance.The August 2026 DeadlineThe prohibited practices provisions of the Act have been in force since February 2025 and the governance rules for general-purpose AI models became applicable in August 2025. But the full obligations for high-risk AI systems take effect on August 2, 2026.Organisations without a verified, technical AI inventory will not be able to demonstrate compliance with the most basic requirement the Act imposes. Regulators will not accept outdated spreadsheets as evidence of ongoing governance.The first step to EU AI Act compliance is knowing what you are governing. This requires automation, not administration.

The post The Shadow AI Trap: Why Your AI Inventory is Your Biggest EU AI Act Compliance Risk – FireTail Blog appeared first on Security Boulevard.

Apr 16, 2026 - Lina Romero - When GDPR arrived, the organisations that had mistaken documentation for capability were the ones that struggled the most. They had policies about data retention but no technical controls enforcing those policies. They had breach notification procedures but no systems capable of detecting a breach in time to use them.The EU AI Act is heading for a similar reckoning. And Article 12 is where most organisations will feel it first.Article 12High-risk AI systems shall technically allow for the automatic recording of events over the lifetime of the system.‍Technically means the logging capability must be built into or applied to the system itself. A manual process for exporting logs, or a human who periodically reviews AI outputs and writes notes, does not satisfy this requirement.‍Automatic means logs are generated without operator intervention at the moment events occur. Scheduled exports do not count. Human-triggered captures do not count.‍Lifetime means from the moment a high-risk AI system is deployed until it is decommissioned. Not from the point at which you decided to start logging or your compliance program went live.Article 26(6) requires automatically generated logs to be retained for a minimum of six months. For biometric identification systems, additional specific data must be captured including precise usage periods, reference databases consulted, and the identities of individuals responsible for verifying results.Who This Applies ToThe first question many organisations ask is whether Article 12 applies to them. The answer, for most enterprises using AI in operational contexts, is yes.Under Annex III of the Act, high-risk includes any operation where AI affects hiring, finances, access, healthcare, resource allocation, or fundamental rights. This covers recruitment screening tools, credit and insurance models, employee performance management systems, customer service AI with access to account data, and healthcare triage or administration tools.The regulation draws a clear line between providers, who build and place AI systems on the market, and deployers, who use those systems within their own operations. Most European enterprises are deployers. Deployers must ensure that logs are kept in formats suitable for analysis and must retain them in a way that supports regulatory review and investigation.If you are a deployer using a third-party AI system, the obligation to ensure logging is in place does not disappear. You need to verify that the systems you use can generate the required logs, and that those logs are accessible to you when needed.The Six Gaps Most Organisations Have Right NowBased on what we see across enterprise environments, these are the most common Article 12 failures:Fragmented log sources. AI usage is spread across multiple systems, some cloud-hosted, some embedded in SaaS tools, some running in developer environments. Each generates logs in different formats, stored in different places without a unified view and no reliable way to produce a complete picture when required.Incomplete coverage. Logging may exist for officially sanctioned AI systems but not for the shadow AI running alongside them. An organisation that logs its approved AI but cannot account for the screening browser extension used by three team members has a compliance gap.Log integrity. Article 12 says nothing about how to protect records from tampering. A log file can be modified, overwritten, or deleted without trace unless it is secured through mechanisms independent of the system that generated it. If logs need to hold up in regulatory or judicial proceedings, chain of custody matters.Insufficient retention. Many organisations apply general IT log retention policies that fall short of six months, or apply the six-month requirement inconsistently across systems.No connection to monitoring. Logs that sit in a storage system and are never reviewed until something goes wrong are not a monitoring system. Article 26 requires deployers to actively monitor AI systems for performance and anomalies. Discovery gaps. You cannot log what you cannot see. The organisations most exposed under Article 12 are those that do not have a complete picture of their high-risk AI deployments in the first place.The 15-Minute Discovery StandardThere is a practical metric that every CISO and GRC leader should apply to their organisation's AI readiness. How long does it take to produce a complete, verified inventory of all AI systems currently in use across your environment?If the answer is days or weeks, you are working from a compliance model that cannot keep pace with how AI is actually being adopted inside your organisation. If the answer is never, or only through a manual survey process, you have a fundamental gap.FireTail deploys automated discovery across cloud infrastructure, browser-based activity, and application-layer integrations. Within 15 minutes, you have a living inventory. That inventory drives everything else, automatic log capture from every discovered system, centralised retention with tamper-evident storage, real-time alerting on anomalous activity, and the audit-ready reporting that demonstrates compliance to regulators.FireTail captures the specific data Article 12 requires for high-risk systems. Interaction timestamps, input data classifications, output records, and human review events. Logs are centralised, retained, and exportable for regulatory review.The Enforcement TimelineThe EU AI Act entered into force on August 1, 2024. The full obligations for high-risk AI systems become applicable on August 2, 2026. Prohibited practices have been enforceable since February 2025. National Competent Authorities across EU member states will move into active enforcement mode after that August 2026 date.The organisations that will be best positioned have automated, continuous logging in place now, generating the six months of retained audit trail the regulation requires before enforcement begins. If you start your logging program the day the Act is enforced, you are already behind.Article 12 reflects what the regulation is actually trying to achieve: the ability to understand, retrospectively and in real time, what high-risk AI systems are doing and what impact they are having. Manual documentation is no longer enough.

The post Article 12 and the Logging Mandate: What the EU AI Act Actually Requires – FireTail Blog appeared first on Security Boulevard.

Apr 16, 2026 - Alan Fagan - When it comes to the EU AI Act, many organisations take a manual approach to auditing, which looks impressive on paper but collapses under regulatory scrutiny. They use policies, surveys, working groups, and a well-formatted risk register. However, a manual approach does not provide the continuous, automated, technical control needed to stay compliant under the Act.For European CISOs and GRC leaders who have built their compliance programs on periodic auditing, the EU AI Act represents a shift in what regulators will accept as evidence. Understanding this shift before August 2026 is the difference between being prepared and being penalised.What Made Manual Audits Work BeforeTraditional compliance frameworks like SOC 2, ISO 27001, and even GDPR were largely designed around periodic assurance. You documented your controls. You tested them at intervals. You produced evidence that things were operating as intended at a point in time. Auditors reviewed that evidence and issued an opinion.This model works reasonably well for relatively stable systems where the risk landscape changes slowly, but breaks down entirely in environments where the risk surface is changing continuously, where the subject of the audit can be adopted or modified without any central approval, and where the regulation itself requires not just documentation but demonstrable technical capability.Why Manual Audits Fail the EU AI ActThe velocity problem. AI models iterate frequently. New tools appear constantly. Organisations now manage an average of 490 SaaS applications, with only 47% of those applications authorised. The AI layer on top of that SaaS estate is growing faster than any quarterly audit cycle can track. A manual audit that was accurate in January may be wrong by March, and legally dangerous by August.The self-reporting problem. Manual audits depend on people accurately describing the systems they use. Nearly half of workers admit to adopting AI tools without employer approval, and a significant majority of C-suite executives appear to be doing the same while remaining reluctant to disclose it. An audit that relies on employees and managers to self-report their AI usage will systematically undercount compliance risks.The technical evidence problem. The EU AI Act does not ask whether you have a policy. It asks whether you can prove that policy is being enforced. Article 12 requires that high-risk AI systems technically allow for the automatic recording of events throughout their lifetime. Manual recording does not count. A system that generates logs because someone remembered to export them is not compliant. The logging capability must be built in and automated.The Real Compliance GapThe most common mistake GRC teams are making right now is treating the EU AI Act as a documentation exercise. They are producing AI registers, drafting governance policies, and mapping their systems to risk classifications. All of that work has value, but it addresses the wrong problem.Most compliance failures under Article 12 are not technical shortfalls, but rather failures to capture and prove every obligation in real time. Organisations that have thoughtful policies but incomplete logs will not be able to demonstrate compliance when regulators ask for evidence of what was happening inside their AI systems six months ago.Consider a concrete scenario. A financial services firm uses an AI model to assist with credit assessment, a clear Annex III high-risk use case. The firm has a governance policy, an AI register, and a risk assessment. What it does not have is a centralized log of every query passed to that model, every output it produced, and every human review decision made in response. When a customer challenges a credit decision under Article 86's right to explanation, or a regulator requests evidence of ongoing monitoring under Article 26, the firm cannot produce what is required. The technical infrastructure was never built.Continuous MonitoringShifting from periodic auditing to continuous monitoring requires rethinking the compliance stack. The components that matter under the EU AI Act are:Continuous discovery. Automated identification of AI traffic across your environment, covering cloud workloads, user-facing browser activity, and application-level integrations. This runs constantly, not quarterly.Automated risk classification. Discovered AI tools mapped in real time against the EU AI Act's risk categories. When a new tool appears, it is classified immediately, not at the next audit cycle.Centralised logging. Every interaction with a high-risk AI system is captured automatically, timestamped, and retained. Article 26 requires that automatically generated logs be kept for a period appropriate to the intended use, but at least six months. This cannot be achieved with manual exports or patched-together log management.Real-time alerting. When something anomalous happens, like a system detecting unexpected outputs, a prompt that matches prohibited practice patterns, a data leakage event, your team needs to know immediately. Reactive incident response is not enough.Technical policy enforcement. Rules for what AI can and cannot be used for, enforced at the point of use rather than reviewed after the fact.The GDPR LessonGDPR taught European organisations about the difference between compliance as documentation and compliance as operational reality. Many organisations spent the first two years after GDPR's 2018 enforcement date discovering that their Subject Access Request processes did not work, their data maps were incomplete, and their policies had never been technically enforced.The EU AI Act's obligations are more technically demanding than GDPR, its enforcement timeline is clear, and the fine structure is more severe, making AI Act violations potentially more expensive than even the most serious GDPR breaches.Organisations that treat the Act as a documentation exercise will repeat the GDPR experience. Those that build technical compliance infrastructure now will be in a fundamentally different position when enforcement begins.FireTail was built for exactly this transition. From periodic auditing to continuous governance, from policy documents to automated enforcement, from reactive incident response to real-time detection and control.The question is not whether you have completed your AI Act checklist. It is whether your AI systems are actually being governed, right now, in a way you could prove to a regulator today.‍

The post Beyond the Spreadsheet: Why Manual AI Audits Are an EU AI Act Compliance Liability – FireTail Blog appeared first on Security Boulevard.

A vulnerability classified as critical was found in Sun Solaris 2.3/2.4/2.5/2.5.1. Affected is an unknown function of the component ps Command. Such manipulation leads to memory corruption. This vulnerability is listed as CVE-1999-0301. The attack must be carried out locally. In addition, an exploit is available. Upgrading the affected component is advised.

A vulnerability, which was classified as problematic, was found in IBM AIX. Affected by this issue is some unknown functionality of the component Syslog. Executing a manipulation can lead to denial of service. This vulnerability is registered as CVE-1999-0566. It is possible to launch the attack remotely. No exploit is available. You should upgrade the affected component.

A vulnerability has been found in Netscape Navigator 4.01/4.06/4.07/4.08/4.5 and classified as critical. This affects an unknown part of the component Java Socket Handler. The manipulation leads to improper privilege management. This vulnerability is documented as CVE-1999-1262. The attack can be initiated remotely. There is not any exploit available. The affected component should be upgraded.

A vulnerability was found in Microsoft Internet Explorer 3.0 and classified as problematic. This vulnerability affects unknown code of the component Clear History Handler. The manipulation results in information disclosure. This vulnerability is reported as CVE-1999-1446. The attack requires a local approach. No exploit exists. It is suggested to upgrade the affected component.

A vulnerability was found in ISC BIND 4.9.5/8.1. It has been declared as critical. Impacted is an unknown function of the component Query ID Handler. Such manipulation leads to improper authentication. This vulnerability is traded as CVE-1999-0024. The attack may be launched remotely. There is no exploit available. This vulnerability is historically impactful due to its background and the reception it garnered. It is recommended to upgrade the affected component.

A vulnerability was found in Blue World Communications Lasso Cgi. It has been rated as critical. The affected element is an unknown function. Performing a manipulation results in improper privilege management. This vulnerability is known as CVE-1999-1250. Remote exploitation of the attack is possible. No exploit is available.

A vulnerability identified as critical has been detected in Great Circle Associates Majordomo 1.94.3. This affects an unknown function of the component Reply-To Field Handler. The manipulation as part of Metacharacter leads to improper privilege management. This vulnerability is uniquely identified as CVE-1999-1220. The attack is possible to be carried out remotely. No exploit exists.

A vulnerability marked as problematic has been reported in IBM AIX 3.1/3.2/3.2.4/3.2.5. Affected is an unknown function of the component bugfilter. This manipulation causes improper privilege management. The identification of this vulnerability is CVE-1999-0115. The attack can only be executed locally. Furthermore, there is an exploit available. It is suggested to upgrade the affected component.

A vulnerability classified as critical has been found in OReilly Website 2.0. Affected by this issue is some unknown functionality of the component Uploader. Performing a manipulation results in improper privilege management. This vulnerability is identified as CVE-1999-0177. The attack can be initiated remotely. There is not any exploit available.

A vulnerability has been found in HP HP-UX 9/10 and classified as problematic. Impacted is an unknown function of the component X Window. This manipulation causes improper authentication. This vulnerability is registered as CVE-1999-1133. The attack needs to be launched locally. No exploit is available. The affected component should be upgraded.

A vulnerability was found in IBM Lotus cc:Mail 8.0. It has been classified as problematic. The impacted element is an unknown function of the component Postoffice Password Handler. Performing a manipulation results in missing encryption of sensitive data. This vulnerability is reported as CVE-1999-1275. The attack requires a local approach. No exploit exists. Upgrading the affected component is recommended.