Tag: vulnerability

Bring Your Own Vulnerable Driver (BYOVD) is a well-known post-exploitation technique used by adversaries. This blog post is part of a series. We will see how to abuse a vulnerable driver to gain access to Ring-0 capabilities. In this first post we describe in detail the exploitation of vulnerabilities found in a signed Lenovo driver on Windows.

On August 20th, Apple released an out-of-band security fix for its main operating systems. This patch allegedly fixes CVE-2025-43300, an out-of-bounds write, addressed with improved bounds checking in the ImageIO framework. In this blog post we provide a root cause analysis of the vulnerability.

A technical exploration of Local Privilege Escalation Vulnerability in ControlPlane on macOS.

The following article explains how, during an audit, we examined Moodle (v4.4.3) and found ways of bypassing all the restrictions preventing SSRF vulnerabilities from being exploited.

The Open Source Technology Improvement Fund, Inc, thanks to funding provided by Sovereign Tech Fund, engaged with Quarkslab to perform a security audit of PHP-SRC, the interpreter of the PHP language.

A signature verification bypass in a function that verifies the integrity of ZIP archives in the AOSP framework

A technical exploration of a trivial Local Privilege Escalation Vulnerability in CCleaner <= v1.18.30 on macOS.

Following the introduction of crypto-condor and differential fuzzing in earlier blogposts, we showcase a use case where Quarsklab's automated test suite for cryptographic implementations allowed us to improve the reference implementation of the recently standardized HQC scheme.

In this series of articles we describe how, during an "assumed breach" security audit, we compromised multiple web applications on our client's network to carry out a watering hole attack by installing fake Single Sign-On pages on compromised servers. In our second episode we take a look at SOPlanning, a project management application that we encountered during the audit.

The following article describes how, during an "assumed breach" security audit, we compromised multiple web applications on our client's network in order to carry out a watering hole attack by installing fake Single Sign-On pages on the compromised servers. This article is the first of a two-part series and explains why it is not enough to just check for CVEs, and why we should dive deep into the code to look for new vulnerabilities in old code bases. We will take phpMyAdmin version 2.11.5 as an example, as this is the version we encountered during the audit.