Astra Security Hexo https://blog.astrasec.org/ All rights reserved 2026, Astra Security Security analysis, reproduced and explained Astra Security 2025-03-25T10:00:00.000Z Astra Security 摘要

CVE-2025-29927 影响部分使用 Next.js Middleware 执行鉴权的自托管应用。攻击者能够构造内部请求头，使框架误判 Middleware 已经执行，从而跳过相关逻辑。如果访问控制只存在于 Middleware 中，受保护路由可能被直接访问。

本报告聚焦防守侧判断：检查部署模式、确认是否把 Middleware 当作唯一授权边界，并尽快升级到官方修复版本。

根因

Next.js 使用内部请求头追踪 Middleware 递归调用。受影响版本没有在进入信任边界时充分隔离该内部状态，外部请求因此可以伪造框架本应自行维护的信息。

问题的关键不只是“一个可控请求头”，而是内部控制信号跨越了外部输入边界。应用层若把 Middleware 作为唯一授权点，后续路由就缺少第二道校验。

影响判断

风险通常需要同时满足以下条件：

  1. 应用运行在受影响的 Next.js 版本上；
  2. 使用 Middleware 执行认证或授权；
  3. 目标路由本身没有重复校验权限；
  4. 部署链路没有移除相关内部请求头。

仅使用静态导出，或由托管平台在边缘层消除该攻击面的场景，需要结合官方公告单独判断。

缓解与修复

  • 按官方安全公告升级到对应主版本的已修复版本。
  • 无法立即升级时，在反向代理或负载均衡层移除外部传入的 x-middleware-subrequest 请求头。
  • 把关键权限校验放到数据访问或业务处理层，不把 Middleware 作为唯一安全边界。
  • 在升级后重新测试未认证访问、低权限访问和直接路由访问。

参考资料

]]> https://blog.astrasec.org/zh-cn/research/cve-2025-29927-nextjs/ 2025-03-22T02:00:00.000Z 摘要

CVE-2025-29927 影响部分使用 Next.js Middleware 执行鉴权的自托管应用。攻击者能够构造内部请求头，使框架误判]]>

Next.js Middleware 授权绕过 2025-03-25T10:00:00.000Z Astra Security Summary

CVE-2025-29927 affects some self-hosted applications that use Next.js Middleware for authorization. An attacker can craft an internal request header that makes the framework treat Middleware as already executed and skip the relevant logic. Protected routes may become directly accessible when access control exists only in Middleware.

This report focuses on defensive triage: identify the deployment model, determine whether Middleware is the only authorization boundary, and upgrade to an officially patched release.

Root cause

Next.js uses an internal request header to track recursive Middleware calls. Affected versions did not sufficiently isolate this internal state at the external trust boundary, allowing a client to supply information that should have been maintained exclusively by the framework.

The core issue is not merely a controllable header. An internal control signal crossed an untrusted input boundary. When an application relies on Middleware as its only authorization layer, downstream routes have no second check.

Exposure conditions

Risk generally requires all of the following conditions:

  1. The application runs an affected Next.js version.
  2. Middleware performs authentication or authorization.
  3. The target route does not independently enforce permissions.
  4. The deployment path does not remove the internal request header.

Static exports and hosting platforms that mitigate the attack at the edge should be evaluated separately against the vendor advisory.

Mitigation and remediation

  • Upgrade to a patched release for the relevant Next.js major version.
  • If immediate patching is impossible, remove externally supplied x-middleware-subrequest headers at the reverse proxy or load balancer.
  • Enforce critical permissions again at the data-access or business-logic layer.
  • After upgrading, retest unauthenticated, low-privilege, and direct-route access.

References

]]> https://blog.astrasec.org/research/cve-2025-29927-nextjs/ 2025-03-22T02:00:00.000Z Summary

CVE-2025-29927 affects some self-hosted applicatio]]>

Next.js Middleware Authorization Bypass 2025-03-25T10:00:00.000Z Astra Security Summary

CVE-2024-3094 was a supply-chain attack against the release process of an open-source project. Much of the malicious logic was delivered through release archives and their build process rather than appearing plainly in the public source tree. That difference made routine source review less likely to identify the behavior quickly.

The incident demonstrates that a version number, a source repository, and a final build artifact are not automatically equivalent trust objects.

Affected scope

The primary affected releases were XZ Utils 5.6.0 and 5.6.1. Practical exposure depended on the distribution, build parameters, architecture, and service combination. Most stable Linux distributions did not formally ship these versions, while rolling releases, testing branches, and prerelease environments may have included them.

Defensive checks

  • Use a software inventory to locate every XZ Utils 5.6.0 or 5.6.1 installation.
  • Check container images, build caches, and manually installed paths in addition to package-manager databases.
  • Revert to a version explicitly identified as safe by the relevant distribution and rebuild potentially contaminated images.
  • Compare distribution advisories to confirm package origin, signatures, and build timelines.

Long-term lessons

The lasting value of this incident is in build and release security. Reproducible builds, release-archive-to-source diffing, maintainer account security, and behavioral baselines for high-impact dependencies should all be part of supply-chain defense.

References

]]> https://blog.astrasec.org/research/cve-2024-3094-xz-utils/ 2024-03-29T04:00:00.000Z Summary

CVE-2024-3094 was a supply-chain attack against th]]>

XZ Utils Supply-Chain Backdoor Review 2024-04-02T01:00:00.000Z Astra Security 摘要

CVE-2024-3094 是一次针对开源项目发布流程的供应链攻击。恶意逻辑主要存在于发布归档及其构建流程中，而不是以直观形式出现在公开 Git 源码里；这让常规源码审查难以及时发现异常。

事件提醒我们：版本号、源码仓库和最终构建产物并不是天然等价的信任对象。

影响范围

核心受影响版本为 XZ Utils 5.6.0 和 5.6.1。实际风险与发行版、构建参数、体系结构及服务组合有关。多数稳定版 Linux 发行版没有正式发布这些版本，但滚动发行版、测试分支和部分预发布环境可能曾经包含它们。

防守检查

  • 建立软件物料清单，定位所有 XZ Utils 5.6.0/5.6.1 实例。
  • 不只检查包管理器数据库，也检查容器镜像、构建缓存和手工安装路径。
  • 回退到发行版明确标记为安全的版本，并重新构建可能受污染的镜像。
  • 比对发行版公告，确认包的来源、签名和构建时间线。

研究结论

这起事件的长期价值在于构建与发布安全：可复现构建、发布归档与源码的差异审计、维护者账号保护，以及对高影响依赖的行为基线，都应成为供应链防御的一部分。

参考资料

]]> https://blog.astrasec.org/zh-cn/research/cve-2024-3094-xz-utils/ 2024-03-29T04:00:00.000Z 摘要

CVE-2024-3094 是一次针对开源项目发布流程的供应链攻击。恶意逻辑主要存在于发布归档及其构建流程中，而不是以直观形式出现在公开 G]]>

XZ Utils 供应链后门事件复盘 2024-04-02T01:00:00.000Z Astra Security Summary

Log4Shell demonstrated that log data is still untrusted input. When an application passed attacker-controlled strings to an affected Log4j 2 release, message lookup behavior could initiate JNDI access and, under the necessary runtime conditions, lead to remote code execution.

Why cleanup is difficult

Log4j is frequently present as an indirect dependency in large Java applications, commercial products, device firmware, and legacy deployments. Searching only the application root for JAR files can miss nested archives, container layers, old images, offline nodes, and vendor-packaged components.

Remediation guidance

  • Begin with asset and dependency inventories rather than treating internet scanning as a substitute for internal discovery.
  • Install a vendor-supported safe version and verify the classpath that the application actually loads.
  • Remove old container images, build caches, and rollback packages so vulnerable releases cannot return to production.
  • Retain detection for unusual outbound DNS, LDAP, and RMI connections.
  • Turn component discovery into a continuous software supply-chain control instead of a one-time incident script.

References

]]> https://blog.astrasec.org/research/cve-2021-44228-log4shell/ 2021-12-10T00:00:00.000Z Summary

Log4Shell demonstrated that log data is still untr]]>

Log4Shell Attack Surface and Long-Term Remediation 2024-01-18T08:30:00.000Z Astra Security 摘要

Log4Shell 展示了“日志数据也是不可信输入”。当应用把攻击者可控字符串交给受影响版本的 Log4j 2 处理时，消息查找机制可能触发 JNDI 访问；结合运行时条件，最终可造成远程代码执行。

为什么难以一次清理

Log4j 经常作为间接依赖存在于大型 Java 应用、商业软件、设备固件和历史部署中。只搜索应用根目录的 JAR 文件容易漏掉嵌套归档、容器层、旧镜像、离线节点和供应商打包组件。

治理建议

  • 以资产清单和依赖关系为起点，不以公网扫描结果代替内部排查。
  • 使用厂商支持的安全版本，并验证应用实际加载的类路径。
  • 清理旧容器镜像、构建缓存和回滚包，避免漏洞版本重新进入生产。
  • 对 DNS、LDAP/RMI 等异常出站连接保留检测能力。
  • 将组件识别方法沉淀为持续的软件供应链检查，而不是一次性应急脚本。

参考资料

]]> https://blog.astrasec.org/zh-cn/research/cve-2021-44228-log4shell/ 2021-12-10T00:00:00.000Z 摘要

Log4Shell 展示了“日志数据也是不可信输入”。当应用把攻击者可控字符串交给受影响版本的 Log4j 2 处理时，消息查找机制可能触发]]>

Log4Shell 攻击面与长期治理 2024-01-18T08:30:00.000Z