Global Security Mag Online

Vigilance.fr - Exim: buffer overflow via SQlite Database Field, analyzed on 15/12/2025

Vigilance.fr — 2026-09-15T05:00:00Z

An attacker can trigger a buffer overflow of Exim, via SQlite Database Field, in order to trigger a denial of service, and possibly to run code.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Exim : buffer overflow via SQlite Database Field, analysé le 15/12/2025

Vigilance.fr — 2026-09-15T05:00:00Z

Un attaquant peut provoquer un buffer overflow de Exim, via SQlite Database Field, afin de mener un déni de service, et éventuellement d'exécuter du code.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Pacing AI innovation? What gov'ts can/can't do, what orgs. Must

2026-09-14T21:42:17Z

Following this weekend's essay from Anthropic CEO Dario Amodei (linked at bottom) recommending pacing AI development, here are expert perspectives on the pace of AI frontier models, what governments can and can't do, and how (and whether) businesses can keep their AI agents in check and within the organization's boundaries.

Ted Miracco, CEO, Approov

"Government regulations will never move fast enough to keep pace with AI development, but the industry doesn't need to wait for governments to add guardrails. The most effective safeguard is simple product liability. If AI companies are held legally and financially responsible for the misuse of their products, safety could become a foundational feature rather than an afterthought. Today, we need to be less concerned about AI gaining sentience and spinning up its own attacks on humanity. The real, immediate dangers involve bad actors weaponizing AI as a force multiplier to cripple critical infrastructure or potentially paralyze the banking system."

Jeremiah Fowler, Cybersecurity Researcher, Black Hills Information Security

"The uncomfortable truth is that AI companies have an incentive to develop advanced models that are better than their competition. In my opinion, voluntary restraint will likely not be a real solution because nobody wants to fall behind in the AI arms race. I don't mean that in terms of cyberwarfare or conflict (yet), but it is good that we are starting the conversation around the worst-case scenarios and how to prevent them.

History has shown us that the approach of letting the market or industry regulate itself doesn't always work and in reality, technology and innovation are moving light speed and far faster than oversight or regulation can keep up with. I think we do need real guardrails on AI. In many cases it seems like functionality was launched first and now we are at the stage where security needs to be added after realizing there have been incidents and the risks are real. Any serious AI guardrails should have enforceable minimum safety standards, independent testing and auditing, limits on autonomous permissions, and the most important part, don't fully remove the humans."

Eric Capuano, Director of SOC Operations, Black Hills Information Security

"The OpenAI incident in July is a useful example. A model given a testing goal went outside its lane, got into another company's systems, and the operators found out after the fact. That is not a swarm taking over the internet. That is an agent with too much access, too little scoping, and nobody watching the logs in real time. Every SOC has seen that exact failure with a human contractor or a misconfigured service account. The difference is speed and volume.

Companies do not need to wait on Washington for the fixes, because the fixes aren't new. Every agent gets its own identity with the narrowest permissions that still let it do the job. Agents run on segmented infrastructure with default-deny egress, so an agent cannot reach a target that it was never supposed to touch. Every action the agent takes is logged as an action, not buried in a chat transcript, and those logs land in the same place the SOC already monitors. Anything that writes, deletes, moves money, or touches production requires a human approval step until you have enough history to justify removing it. Someone owns the kill switch and has tested it.

Where government can help is on the after side. The frontier labs are proposing embedded outside evaluators, which is fine, but evaluation before deployment tells you what a model does in a lab. What defenders need is mandatory reporting when an agent causes a security incident in the field, with enough technical detail that the rest of us can build detections from it. We did not learn to defend against ransomware from pre-release testing. We learned from incident writeups. Agents will be the same."

Ryan McCurdy, VP, Liquibase:

"No one should expect AI agents to be perfectly predictable, instead, we should build around the assumption that they won't be. As agents gain access to more tools, credentials, and production systems, enterprises need to define what they can access, what they can change, what they can decide on their own, and what policies have to be met before an action reaches a critical system.

The answer also can't be putting a human in front of every decision. AI is moving too quickly and that defeats much of the reason companies are adopting agents in the first place. Governance has to operate at the same speed as the systems it's governing.

Government policy and the AI industry have a role in establishing standards for how these systems are developed and tested. But every enterprise still has to decide where AI is allowed to act inside its own environment. You don't need to predict every decision an agent might make if you control what it's allowed to turn into action."

Waseem Ahmed, Head of Engineering, Secure.com

"The essay lands at the right time because AI agents are already acting on their own inside real company systems, and the OpenClaw ban wave earlier this year showed how fast that goes wrong when an agent has broad access and no leash.

Slowing the pace matters, but enterprises cannot wait for that. The controls that protect us most are least privilege, network isolation, and sandboxing, so an agent can only touch what its job needs and nothing else.

Give every agent its own identity, log every action it takes, and never let it run high-impact steps like disabling accounts or changing settings without a real person approving first. Traditional testing alone will not keep up, so we watch these agents continuously in production.

Independent oversight should mean outside reviewers who can inspect the logs and confirm the agent stayed inside the boundaries we set."

Denis Calderone, CTO, Suzu Labs

"Enterprises must secure AI agents that can act autonomously across corporate systems - the agent is the new contractor or the new internal threat vector. The agent has a specific job, specific access requirements, and a bounded set of actions it should be performing. Enterprises need to treat every AI agent the same way they'd treat any other agent on the network, human or otherwise. Every agent must have its own machine identity, task-scoped credentials that expire when the job is done, and observability into everything it does. Not a shared service account or API token, but instead a distinct, auditable identity per agent per task.

Because agents are purpose-built, modeling normal behavior is easier than it is for humans. A human user's workday is unpredictable. An agent doing invoice processing should only be touching invoices. Any deviation from that pattern is an immediate signal, cleaner than those you typically get from human behavioral analytics.

Enterprises need to be disciplined about keeping the security and observability stack architecturally separated from the agent's operational environment. For example, say you deploy an agent to handle IT operations such as patching, config changes, routine maintenance, etc. If that agent has visibility into the monitoring and alerting system that flags anomalous behavior, it will learn which actions trigger alerts and potentially choose to route around them. Not because it's adversarial, but because it might just be trying to remove friction between itself and some obstacle in the way of achieving its goal. This is basically what happened in the OpenAI-Hugging Face incident where 700 agents organized a collective R&D effort to reverse-engineer and defeat the evaluation system scoring them; it was easier to cheat to achieve the task. The agents worked hard to figure out how to generate its own flags, and then how to defeat a presumed causal check in the scoring workflow.

This the same architectural principle and precautions we take when implementing a SIEM. We deploy out of band, on a separate management network and we try to make it invisible to the workloads it monitors."

Donald McFarlane, Board Member, Xcape Inc.

"AI does not develop an agenda; its operators do. When we give an autonomous system powerful access and ability to act at machine speed, they will continue to prove highly capable.

Rules enacted in the name of safety must not become a moat against competition or progress. Enormous compliance costs may be manageable for the handful of companies already spending billions building frontier models, while becoming a substantial barrier to everyone behind them.

Government can help clarify accountability and duties of care, and facilitate strong information sharing and collective defense, which is an area where we sorely need more effective public-private partnerships.

But safeguards should focus on how these systems are used and deployed, rather than deciding who is allowed to build powerful AI in the first place.

The goal should be safer deployment without pulling up the drawbridge on innovation."

Revolut tricked into handing over passports, financial data through fake gov't requests - Expert Comments

Suzu Labs, Black Hills Information Security and Xcape Inc. — 2026-09-14T21:06:58Z

Digital banking and financial services platform Revolut has confirmed a data breach after an unauthorized party used an email account on a legitimate government agency domain to submit fraudulent requests for customer information, according to crypto investigator ZachXBT, who shared a customer notification sent out by the company. Revolut said its own systems were not compromised and customer funds were not affected.

The information disclosed may include names, dates of birth, addresses, phone numbers, email addresses and copies of passports and driver's licenses, as well as verification selfies. Some affected customers were also told that account statements, IBANs, withdrawal records and full transaction histories, including Bitcoin transactions, may have been exposed.

Revolut has not disclosed how many customers were affected or identified the government agency whose email domain was used. The company blocked the email address after discovering the scheme.

ZachXBT reported that the incident appeared to target high-net-worth customers, although Revolut has not confirmed that claim. Revolut currently serves more than 80 million customers worldwide.

Experts with Suzu Labs, Black Hills Information Security and Xcape Inc. offer perspectives on the matter.

Denis Calderone, CTO, Suzu Labs:

“This attacker wasn't spoofing a government email address. They were logged into a legitimate government agency's email infrastructure and sent the request from inside it. SPF passed. DKIM passed. And Revolut's compliance team treated that as sufficient verification to release passports, driver's licenses, verification selfies, full transaction histories including Bitcoin activity, IBANs, and withdrawal records for what appears to be a targeted set of high-net-worth customers."

“Think about how most financial institutions handle a wire transfer request. You get the request, you verify it through an independent channel, you call back on a known number, you confirm authorization. Nobody releases six figures based solely on the fact that the email came from a real domain. But that appears to be essentially what happened here with data that, for affected customers, is more damaging than a wire fraud loss. You can reverse a wire. You can't un-leak a passport."

“The FBI's November 2024 Private Industry Notification on fraudulent data requests laid out a model that applies here. That advisory focused on emergency requests, but the core prescriptions are just as relevant for routine government data requests, especially when the data being released is this sensitive. The FBI told companies to "apply critical thinking to any emergency data requests received" and recommended "contacting the sender and originating authority to discuss the request further." Whether a request comes in as an emergency or through standard legal compliance channels, the data being handed over is the same. Passports, KYC selfies, and full financial transaction histories don't become less valuable to an attacker because the request wasn't urgent. Out-of-band verification, callback procedures to independently verified agency contacts, and specialized legal request intake portals should be standard for any government data request involving sensitive customer records, not just the ones that come in marked urgent.”

John Strand, Owner, Black Hills Information Security, Inc.:

“This story just highlights that no matter how advanced defensive technology gets, and no matter how sophisticated attacks become with all the new exploits we're seeing, the human element is still one of the easiest ways to get access to data."

“What makes this one particularly interesting is how targeted the attackers were. To be honest, that makes the attack look even more realistic. They clearly had some understanding of the normal processes, how those processes worked, and the channels these requests would normally come through."

“That's critical for an attacker trying to pull something like this off. And once again, it proves that technology alone is not going to save us.”

Eric Capuano, Director of SOC Operations, Black Hills Information Security:

“Revolut called this a sophisticated external impersonation scam. It was not. Someone sent email from a mailbox on a real government agency domain, and every technical check Revolut ran came back clean because the mail genuinely came from that domain. SPF and DKIM confirm a message came from where it claims. They say nothing about who is sitting at the keyboard. Revolut's own notification says the quiet part out loud: the request carried valid domain authentication, so it was fulfilled. That is authentication being treated as authorization, and it is the entire incident."

“The company says its systems were not compromised, and that is accurate and beside the point. The data walked out through a process working as designed. In most companies the government and law enforcement request queue is a shared mailbox, a person with a legal obligation, and a deadline. There is usually no callback to a number the company looked up itself, no second approver, and no logging that the SOC ever sees. Nobody gets an alert when the compliance team emails passport scans, verification selfies, and a full transaction history to an outside address, because that is a Tuesday for that team. Security spends its budget on the front door and this stuff goes out the loading dock."

“The customers are the ones stuck with it. A password gets rotated in a minute. A passport number, a date of birth, and the selfie you took to open the account do not. Those are the exact artifacts other institutions accept to verify identity and to recover an account, so the people in this set are now easier to impersonate everywhere else they bank. Pair that with full transaction history and Bitcoin records, and whoever received it has a list of who is worth working on and how much they are worth. ZachXBT says it looks like high net worth customers were the target and Revolut has not confirmed that, but targeting would fit what was asked for."

“Three things worth doing this week if you handle customer data. Find out who at your company can fulfill a government or law enforcement request and have them walk you through it while you watch. If the verification step is that the email passed authentication, add an out-of-band callback to a number you pull from the agency's own published directory, plus a second approver for anything involving identity documents or full account history. Then get that queue logged somewhere the SOC reads, because right now most of us cannot even reconstruct what left. And if you have ever received requests from that agency, go pull your mail logs for the same window. A mailbox that gets used once usually gets used more than once.”

Donald McFarlane, Board Member, Xcape Inc.:

“Financial institutions may be required to retain sensitive identity information, but that makes strict controls and data minimization more important, not less."

“We should not be yeeting passports, transaction histories and other sensitive customer data to someone simply because a request arrives from a government email address. A government domain is not a substitute for authenticating a valid warrant and its legal authority, and using a secure process to return the information.”

Vigilance.fr - Siemens SIMATIC S7-PLCSIM Advanced: overload via Multicast Network Traffic, analyzed on 14/07/2026

Vigilance.fr — 2026-09-14T14:51:16Z

An attacker can trigger an overload of Siemens SIMATIC S7-PLCSIM Advanced, via Multicast Network Traffic, in order to trigger a denial of service.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Siemens SIMATIC S7-PLCSIM Advanced : surcharge via Multicast Network Traffic, analysé le 14/07/2026

Vigilance.fr — 2026-09-14T14:51:16Z

Un attaquant peut provoquer une surcharge de Siemens SIMATIC S7-PLCSIM Advanced, via Multicast Network Traffic, afin de mener un déni de service.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Xen: Man-in-the-Middle via XAPI SDKs, analyzed on 14/07/2026

Vigilance.fr — 2026-09-14T14:41:10Z

An attacker can act as a Man-in-the-Middle on Xen, via XAPI SDKs, in order to read or write data in the session.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Xen : Man-in-the-Middle via XAPI SDKs, analysé le 14/07/2026

Vigilance.fr — 2026-09-14T14:41:10Z

Un attaquant peut se positionner en Man-in-the-Middle sur Xen, via XAPI SDKs, afin de lire ou modifier des données de la session.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Notepad++: five vulnerabilities dated 14/07/2026

Vigilance.fr — 2026-09-14T14:39:53Z

An attacker can use several vulnerabilities of Notepad++, dated 14/07/2026.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Notepad++ : cinq vulnérabilités du 14/07/2026

Vigilance.fr — 2026-09-14T14:39:53Z

Un attaquant peut employer plusieurs vulnérabilités de Notepad++, du 14/07/2026.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Apache Tomcat : deux vulnérabilités du 14/07/2026

Vigilance.fr — 2026-09-14T13:30:06Z

Un attaquant peut employer plusieurs vulnérabilités de Apache Tomcat, du 14/07/2026.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Apache Tomcat: two vulnerabilities dated 14/07/2026

Vigilance.fr — 2026-09-14T13:30:06Z

An attacker can use several vulnerabilities of Apache Tomcat, dated 14/07/2026.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Noyau Linux : deux vulnérabilités du 14/07/2026

Vigilance.fr — 2026-09-14T13:27:58Z

Un attaquant peut employer plusieurs vulnérabilités du noyau Linux, du 14/07/2026.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Linux kernel: two vulnerabilities dated 14/07/2026

Vigilance.fr — 2026-09-14T13:27:58Z

An attacker can use several vulnerabilities of the Linux kernel, dated 14/07/2026.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Perl Core : débordement d'entier via S_measure_struct(), analysé le 14/07/2026

Vigilance.fr — 2026-09-14T13:20:09Z

Un attaquant peut provoquer un débordement d'entier de Perl Core, via S_measure_struct(), afin de mener un déni de service, et éventuellement d'exécuter du code.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Perl Core: integer overflow via S_measure_struct(), analyzed on 14/07/2026

Vigilance.fr — 2026-09-14T13:20:09Z

An attacker can trigger an integer overflow of Perl Core, via S_measure_struct(), in order to trigger a denial of service, and possibly to run code.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Perl Core : corruption de mémoire via Regular Expression Matches, analysé le 14/07/2026

Vigilance.fr — 2026-09-14T13:18:37Z

Un attaquant peut provoquer une corruption de mémoire de Perl Core, via Regular Expression Matches, afin de mener un déni de service, et éventuellement d'exécuter du code.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Perl Core: memory corruption via Regular Expression Matches, analyzed on 14/07/2026

Vigilance.fr — 2026-09-14T13:18:37Z

An attacker can trigger a memory corruption of Perl Core, via Regular Expression Matches, in order to trigger a denial of service, and possibly to run code.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Eclipse Jetty : deux vulnérabilités du 14/07/2026

Vigilance.fr — 2026-09-14T13:09:26Z

Un attaquant peut employer plusieurs vulnérabilités de Eclipse Jetty, du 14/07/2026.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Eclipse Jetty: two vulnerabilities dated 14/07/2026

Vigilance.fr — 2026-09-14T13:09:26Z

An attacker can use several vulnerabilities of Eclipse Jetty, dated 14/07/2026.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Eclipse Jetty : deux vulnérabilités du 14/07/2026

Vigilance.fr — 2026-09-14T13:08:24Z

Un attaquant peut employer plusieurs vulnérabilités de Eclipse Jetty, du 14/07/2026.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Eclipse Jetty: two vulnerabilities dated 14/07/2026

Vigilance.fr — 2026-09-14T13:08:24Z

An attacker can use several vulnerabilities of Eclipse Jetty, dated 14/07/2026.

View online : https://vigilance.fr/vulnerability/...

Vulnérabilité dans CPython (14 septembre 2026)

2026-09-14T02:00:00Z

Une vulnérabilité a été découverte dans CPython. Elle permet à un attaquant de provoquer un problème de sécurité non spécifié par l'éditeur.

Voir en ligne : https://www.cert.ssi.gouv.fr/avis/C...

Multiples vulnérabilités dans Microsoft Edge (14 septembre 2026)

2026-09-14T02:00:00Z

De multiples vulnérabilités ont été découvertes dans Microsoft Edge. Elles permettent à un attaquant de provoquer un contournement de la politique de sécurité et un problème de sécurité non spécifié par l'éditeur. Microsoft indique que la vulnérabilité CVE-2026-87491 est activement exploitée.

Voir en ligne : https://www.cert.ssi.gouv.fr/avis/C...

Bulletin d'actualité CERTFR-2026-ACT-039 (14 septembre 2026)

2026-09-14T02:00:00Z

Ce bulletin d'actualité du CERT-FR revient sur les vulnérabilités significatives de la semaine passée pour souligner leurs criticités. Il ne remplace pas l'analyse de l'ensemble des avis et alertes publiés par le CERT-FR dans le cadre d'une analyse de risques pour prioriser l'application des...

Voir en ligne : https://www.cert.ssi.gouv.fr/actual...

Multiples vulnérabilités dans MISP (14 septembre 2026)

2026-09-14T02:00:00Z

De multiples vulnérabilités ont été découvertes dans MISP. Certaines d'entre elles permettent à un attaquant de provoquer un déni de service à distance, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.

Voir en ligne : https://www.cert.ssi.gouv.fr/avis/C...

Multiples vulnérabilités dans Squid (14 septembre 2026)

2026-09-14T02:00:00Z

De multiples vulnérabilités ont été découvertes dans Squid. Certaines d'entre elles permettent à un attaquant de provoquer un déni de service à distance, une atteinte à l'intégrité des données et un contournement de la politique de sécurité.

Voir en ligne : https://www.cert.ssi.gouv.fr/avis/C...

Multiples vulnérabilités dans MongoDB (14 septembre 2026)

2026-09-14T02:00:00Z

De multiples vulnérabilités ont été découvertes dans MongoDB. Certaines d'entre elles permettent à un attaquant de provoquer un déni de service à distance, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.

Voir en ligne : https://www.cert.ssi.gouv.fr/avis/C...

CYBERBREW : Le Nord de la France va bientôt accueillir un nouvel évènement Cyber !

Valentin Jangwa, Global Security Mag — 2026-09-13T17:18:45Z

En effet, le Mardi 15 septembre 2026, à Lille, la première édition de
CYBERBREW sera lancée !

https://cyberbrew.tech/

Une journée qui sera rythmée par des Conférences Cyber, des bières artisanales et des rencontres. Des « talks » pointus et concrets par des expert.e.s cyber, des partages d'expériences et de bonnes pratiques.
Bières artisanales sélectionnées. Des brasseurs passionnés, des rencontres et des dégustations tout au long de la journée.

Ecosystème & networking. Échanges, partages et connexions dans une ambiance
détendue et conviviale.

Des sujets autour de :
Keynotes, RETEX, Incident Response, Blue Team, ICS / SCADA, Pentest, VOC, OSINT Forensic.

De bons moments en perspective, au sein d'un lieu emblématique :
EURATECHNOLOGIES
165 Av. de Bretagne, 59000 Lille.

Vigilance.fr - GIMP: buffer overflow via PSP File Parsing, analyzed on 13/07/2026

Vigilance.fr — 2026-09-13T14:19:55Z

An attacker can trigger a buffer overflow of GIMP, via PSP File Parsing, in order to trigger a denial of service, and possibly to run code.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - GIMP : buffer overflow via PSP File Parsing, analysé le 13/07/2026

Vigilance.fr — 2026-09-13T14:19:55Z

Un attaquant peut provoquer un buffer overflow de GIMP, via PSP File Parsing, afin de mener un déni de service, et éventuellement d'exécuter du code.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Avahi: buffer overflow via Resource Records Names, analyzed on 13/07/2026

Vigilance.fr — 2026-09-13T11:49:59Z

An attacker can trigger a buffer overflow of Avahi, via Resource Records Names, in order to trigger a denial of service, and possibly to run code.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Avahi : buffer overflow via Resource Records Names, analysé le 13/07/2026

Vigilance.fr — 2026-09-13T11:49:59Z

Un attaquant peut provoquer un buffer overflow de Avahi, via Resource Records Names, afin de mener un déni de service, et éventuellement d'exécuter du code.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Contao: Server-Side Request Forgery via RSS Feed URLs, analyzed on 13/07/2026

Vigilance.fr — 2026-09-13T11:43:32Z

An attacker can trigger a Server-Side Request Forgery of Contao, via RSS Feed URLs, in order to force the server to send queries.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Contao : Server-Side Request Forgery via RSS Feed URLs, analysé le 13/07/2026

Vigilance.fr — 2026-09-13T11:43:32Z

Un attaquant peut provoquer un Server-Side Request Forgery de Contao, via RSS Feed URLs, afin de forcer le serveur à envoyer des requêtes.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - CUPS: information disclosure via Root-side Banner File, analyzed on 13/07/2026

Vigilance.fr — 2026-09-13T11:39:29Z

An attacker can bypass access restrictions to data of CUPS, via Root-side Banner File, in order to read sensitive information.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - CUPS : obtention d'information via Root-side Banner File, analysé le 13/07/2026

Vigilance.fr — 2026-09-13T11:39:29Z

Un attaquant peut contourner les restrictions d'accès aux données de CUPS, via Root-side Banner File, afin d'obtenir des informations sensibles.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - FasterXML Jackson Core: overload via maxNumberLength bypass, analyzed on 13/07/2026

Vigilance.fr — 2026-09-13T11:30:45Z

An attacker can trigger an overload of FasterXML Jackson Core, via maxNumberLength bypass, in order to trigger a denial of service.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - FasterXML Jackson Core : surcharge via maxNumberLength bypass, analysé le 13/07/2026

Vigilance.fr — 2026-09-13T11:30:45Z

Un attaquant peut provoquer une surcharge de FasterXML Jackson Core, via maxNumberLength bypass, afin de mener un déni de service.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - FasterXML Jackson Databind : accès en écriture via JsonUnwrapped Container Properties, analysé le 13/07/2026

Vigilance.fr — 2026-09-13T11:27:01Z

Un attaquant peut contourner les restrictions d'accès de FasterXML Jackson Databind, via JsonUnwrapped Container Properties, afin de modifier des données.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - FasterXML Jackson Databind: write access via JsonUnwrapped Container Properties, analyzed on 13/07/2026

Vigilance.fr — 2026-09-13T11:27:01Z

An attacker can bypass access restrictions of FasterXML Jackson Databind, via JsonUnwrapped Container Properties, in order to alter data.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - FasterXML Jackson Databind : accès en lecture et écriture via PropertyNamingStrategy JsonIgnore Bypass, analysé le 13/07/2026

Vigilance.fr — 2026-09-13T11:25:10Z

Un attaquant peut contourner les restrictions d'accès de FasterXML Jackson Databind, via PropertyNamingStrategy JsonIgnore Bypass, afin de lire ou modifier des données.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - FasterXML Jackson Databind: read-write access via PropertyNamingStrategy JsonIgnore Bypass, analyzed on 13/07/2026

Vigilance.fr — 2026-09-13T11:25:10Z

An attacker can bypass access restrictions of FasterXML Jackson Databind, via PropertyNamingStrategy JsonIgnore Bypass, in order to read or alter data.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - FasterXML Jackson Databind : accès en lecture et écriture via Creator Properties Bypass, analysé le 13/07/2026

Vigilance.fr — 2026-09-13T11:22:43Z

Un attaquant peut contourner les restrictions d'accès de FasterXML Jackson Databind, via Creator Properties Bypass, afin de lire ou modifier des données.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - FasterXML Jackson Databind: read-write access via Creator Properties Bypass, analyzed on 13/07/2026

Vigilance.fr — 2026-09-13T11:22:43Z

An attacker can bypass access restrictions of FasterXML Jackson Databind, via Creator Properties Bypass, in order to read or alter data.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - IBM Db2: multiple vulnerabilities dated 13/07/2026

Vigilance.fr — 2026-09-13T08:52:21Z

An attacker can use several vulnerabilities of IBM Db2, dated 13/07/2026.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - IBM Db2 : multiples vulnérabilités du 13/07/2026

Vigilance.fr — 2026-09-13T08:52:21Z

Un attaquant peut employer plusieurs vulnérabilités de IBM Db2, du 13/07/2026.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Apache Log4j API: write access via Non-finite Floating-point Values, analyzed on 13/07/2026

Vigilance.fr — 2026-09-13T08:45:16Z

An attacker can bypass access restrictions of Apache Log4j API, via Non-finite Floating-point Values, in order to alter data.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Apache Log4j API : accès en écriture via Non-finite Floating-point Values, analysé le 13/07/2026

Vigilance.fr — 2026-09-13T08:45:16Z

Un attaquant peut contourner les restrictions d'accès de Apache Log4j API, via Non-finite Floating-point Values, afin de modifier des données.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - OPAM: directory traversal via Install File Directives, analyzed on 13/07/2026

Vigilance.fr — 2026-09-13T08:41:14Z

An attacker can traverse directories of OPAM, via Install File Directives, in order to write a file outside the service root path.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - OPAM : traversée de répertoire via Install File Directives, analysé le 13/07/2026

Vigilance.fr — 2026-09-13T08:41:14Z

Un attaquant peut traverser les répertoires de OPAM, via Install File Directives, afin de modifier un fichier situé hors de la racine du service.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - p11-kit: overload via p11_rpc_message_get_attribute(), analyzed on 13/07/2026

Vigilance.fr — 2026-09-13T08:35:35Z

An attacker can trigger an overload of p11-kit, via p11_rpc_message_get_attribute(), in order to trigger a denial of service.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - p11-kit : surcharge via p11_rpc_message_get_attribute(), analysé le 13/07/2026

Vigilance.fr — 2026-09-13T08:35:35Z

Un attaquant peut provoquer une surcharge de p11-kit, via p11_rpc_message_get_attribute(), afin de mener un déni de service.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Apple iOS | macOS: multiple vulnerabilities dated 12/12/2025

Vigilance.fr — 2026-09-12T20:38:20Z

An attacker can use several vulnerabilities of Apple iOS | macOS, dated 12/12/2025.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Apple iOS | macOS : multiples vulnérabilités du 12/12/2025

Vigilance.fr — 2026-09-12T20:38:20Z

Un attaquant peut employer plusieurs vulnérabilités de Apple iOS | macOS, du 12/12/2025.

Voir en ligne : https://vigilance.fr/vulnerabilite/...

Vigilance.fr - Apache Tika: external XML entity injection via PDF XFA File, analyzed on 12/12/2025

Vigilance.fr — 2026-09-12T10:24:03Z

An attacker can transmit malicious XML data to Apache Tika, via PDF XFA File, in order to read a file, scan sites, or trigger a denial of service.

View online : https://vigilance.fr/vulnerability/...

Vigilance.fr - Apache Tika : injection d'entité XML externe via PDF XFA File, analysé le 12/12/2025

Vigilance.fr — 2026-09-12T10:24:03Z

Un attaquant peut transmettre des données XML malveillantes vers Apache Tika, via PDF XFA File, afin de lire un fichier, de scanner des sites, ou de mener un déni de service.

Voir en ligne : https://vigilance.fr/vulnerabilite/...