Authorized offensive security
Manual, exploit-oriented assessment of web applications, native clients, APIs, and cloud control planes. Findings are evidence-backed, mapped to reachable impact, and closed with a retest.
News
The news desk: cybersecurity stories and high-severity vulnerabilities, newest publish date first.
Threat actors are actively exploiting a critical OS command injection vulnerability in SiteGuard Server Edition, tracked as CVE-2026-106931. The flaw resides in the default statistics component and grants unauthenticated remote execution with root or SYSTEM privileges. SecOps and sysadmins running affected WAF installations must apply vendor patches immediately.
Read briefingSecurity analysts have identified a technique involving orphaned VBA macro projects embedded inside AutoCAD DWG files. This briefing outlines the underlying file structure mechanics, provides a YARA detection rule to identify anomalous artifacts, and details defensive remediation steps for SecOps teams.
CyberSN’s latest jobs report shows a 26.4% decline in U.S. cybersecurity postings to 235,786 between January and September 2026, but a sharp rise in AI security engineer roles. Defenders should assess talent gaps, prioritize AI skill development, and adjust hiring strategies.
ConnectWise disabled seven application identities after attackers gained unauthorized access to Microsoft 365 tenants, suspending its Cloud Backup service. Defenders should verify affected identities, review backup status, audit logs, revoke tokens, and monitor for lateral movement.
In the Linux kernel, the following vulnerability has been resolved: io_uring: fix task_work add use-after-free with SQPOLL For SQPOLL, the sqpoll thread runs task_work off its own list and doesn't need to be told about it, so it can pop and complete a request as soon as mpscq_push() has published it. If that was the last request holding the ring alive, io_ring_exit_work() then frees the ctx, stops the thread, and with it the tctx, while io_req_normal_work_add() is still looking at both after the push: BUG: KASAN: slab-use-after-free in io_req_normal_work_add+0x439/0x510 Read of size 4 at addr ff11000000ca0000 by task repro/55 (...) BUG: KASAN: slab-use-after-free in queue_work_on+0x25/0x70 Write of size 8 at addr ff11000000c3bd00 by task repro/55 Hold an RCU read lock across the add, like io_req_local_work_add() already does, and have io_ring_exit_work() wait for a grace period for SQPOLL rings as well before freeing the ctx.
In the Linux kernel, the following vulnerability has been resolved: audit: fix exe mark UAF in kill_rules() kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry->rule.exe before removing the rule from the RCU-visible filter lists. After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free. KASAN reports: BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0 Unlink the published rules from the RCU-visible lists and retain them on tree->rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait.
In the Linux kernel, the following vulnerability has been resolved: net: page_pool: fix use-after-free in page_pool_recycle_ring_bulk() With CONFIG_PAGE_POOL_STATS=y, page_pool_recycle_ring_bulk() updates the recycle stats after dropping the producer lock. If it just recycled the last inflight netmems of a pool being destroyed, page_pool_release() can pass its producer-lock barrier and free the pool before recycle_stat_add() runs. Commit fcc680a647ba7 ("page_pool: allow mixing PPs within one bulk") moved this stat update after the unlock. Commit 271683bb2cf32 ("page_pool: Fix use-after-free in page_pool_recycle_in_ring") later added the barrier, but only fixed page_pool_recycle_in_ring(). Move the update back under the lock.
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds when handling team device events The mlx5_handle_changeupper_event() and mlx5_handle_changeinfodata_event() functions check for LAG masters (which includes both bonding and team devices) but only call bonding-specific APIs. When processing team device events, calling bond_slave_get_rcu() and bond_is_slave_inactive() on team_port structures causes KASAN to detect an out-of-bounds memory access since team_port is smaller than bond slave. Fix this by wrapping the bond-specific API calls with a check for bonding devices. This allows the function to still process LAG events for both bonding and teams but only calls bond-specific functions when dealing with actual bonding devices. For mlx5_handle_changeinfodata_event(), keep the explicit bond check as mlx5 doesn't handle state information for team ports anyway. Tested with Mellanox ConnectX-5 on Linux 7.2.0-rc6: - Bonding: PASS (no regressions) - Team device: PASS (no KASAN errors)
Pentesting
Coverage is aligned to OWASP, MASVS, and CIS where it is useful — not as a checklist. The output is a prioritized set of reachable issues your engineers can close this cycle.
Browser apps, SPAs, and the APIs they call — tested as more than one role.
iOS and Android clients treated as hostile, not as a security boundary.
Identities and control planes, not a generic CIS dump of every checkbox.
Design and delivery risk when a full exploit pass is not the first need.
About
RootPwn is an authorized offensive-security practice. We do not run unsolicited tests, sell scan exports, or grade severity without a reachable path. Engagements stay tight: scoped assets, real roles, reproducible evidence, and remediation that matches how the system is actually built. Retest of an in-scope fix is included.
Work starts only after the asset owner authorizes it in writing. We test as the roles you name — anonymous, user, admin, service — and we stop at the boundary you set. If a chain leaves scope, we record the edge and ask before continuing.
We do not replace your scanner subscription, issue a certification, or inflate severity to fill a report. If we cannot demonstrate impact, it is not a finding.
Attack surface
Production compromise is usually a chain: a weak control, a trusted client, an over-privileged identity. We start where that chain is cheapest to pull.
BOLA/IDOR, vertical privilege escalation, and multi-tenant isolation failures across session, JWT, and object-level checks.
Trust policies, public storage, metadata services, and lateral movement from a single over-scoped role or leaked key.
Insecure local storage, pinning bypass, IPC, and APIs that treat the mobile or SPA client as a security boundary.
Methodology
We inventory in-scope apps, APIs, identities, and cloud assets, then test as a privileged and unprivileged user. Work is manual-first: authentication, session handling, access control, injection, deserialization, SSRF, and business-logic abuse that scanners miss. Each issue ships with reproduction, impact, and a concrete fix — then we retest the patch.
Process
No surprise traffic. Scope, roles, and a start window are agreed first. The report is written for the engineer who has to fix the issue — then we retest.
Product, environments, identity model, and deadline. We reply with a proposed scope.
Named assets, roles, out-of-scope edges, and a written authorization from the owner.
Authenticated testing across the agreed surfaces. Chains are pursued to reachable impact.
Reproduction, evidence, impact, and a concrete fix — prioritized, not padded.
The in-scope patch is retested. Residual risk is stated plainly if anything remains.
Object-level access on invoice API
Role, request, and steps an engineer can replay. No “tool said so” findings.
Severity follows a reachable path — data, identity, or control — not a CVSS guess in isolation.
A concrete remediation, then one retest of that in-scope change.
Questions
Short answers to what teams usually ask before they authorize an assessment.
No. We do not run unsolicited tests. Written authorization from the asset owner is required before any traffic is sent.
Yes, when the rules of engagement say so. Staging is often cleaner for destructive checks. We agree environments, rate limits, and stop conditions up front.
Neither. We do not sell scanner exports or issue a compliance badge. The output is a prioritized set of reachable issues with reproduction and a fix.
The product, environments (prod / staging), identity model, in-scope assets, and any deadline. After intake we send a proposed scope, rules of engagement, and a start window.
Yes. One retest of an in-scope fix is part of the engagement. Out-of-scope work or a new surface is a separate scope.
Teams that want an unsolicited test, a checkbox scan, or a report without authorization. If you do not own the asset, we will not test it.
Engagement intake
Choose your email provider, then pick a primary focus. We open a draft to [email protected] with subject and details filled for that focus — complete the blanks and send. No traffic is sent without written authorization from the asset owner.
Choose email provider
Primary focus
Select a primary focus to continue.
Draft opened
Send the email from your mail app. This page stays open — switch back here when you are done.
