Skip to content
KitploitKITPLOIT
工具漏洞利用博客
Log in
提交
工具漏洞利用博客
提交

黑客、渗透测试和网络安全工具,武装您的安全武器库!

Kitploit 是一个黑客、网络安全和渗透测试工具的目录。发现最新的项目更新,查找漏洞、分析系统、自动化测试并加强你的安全。

订阅源联系隐私© 2026 Kitploit

工具目录

分类

查看所有分类
Loading categories
工具/GitHubGitHub/roodhelios/cve-2022-26134-ognl-injection
Payload GenerationVulnerability AnalysisExploitationWeb Application ExploitationPenetration Testing
GitHubroodhelios/cve-2022-26134-ognl-injection

CVE-2022-26134-OGNL-Injection

Exploit for CVE-2022-26134, an OGNL injection vulnerability in Atlassian Confluence Server and Data Center, enabling unauthenticated remote code execution.

查看仓库
5416小时57分前尚未审核

最受欢迎

查看全部 →

发现我们社区最常用的工具。

探索所有工具

浏览我们的工具集合

查看所有工具 →
分享
内容在请求的语言中不可用。显示英文版本。

CVE-2022-26134: defensive case study

Local Python workflows for turning request-URI evidence into a reproducible analyst case and reviewing claimed Confluence mitigation evidence. The original academic paper and slides are preserved. These tools do not send exploit requests or scan hosts.

Start with the complete local case workflow

Use Python 3.11 or newer. From the repository root, run with the standard library:

python -m detection.demo

The fixture report becomes one case routed to application-security. The command stores it in temporary SQLite, retries the insert without a duplicate, and verifies the stored evidence. Temporary files are removed. This establishes local consistency, not source authenticity, incident confirmation or successful mitigation.

Exercise native SQLite recovery across abrupt local writer process exits:

python -m detection.demo_recovery

Expect case_recovery_exercise_passed: an exit before commit leaves zero cases; an exit after commit leaves one. Reopening, integrity checks and repeated retries must end with exactly one verified case in each scenario. Only synthetic temporary databases are used. See the recovery boundaries before interpreting this as durability evidence.

Exercise the separate cluster-manifest publication boundary on POSIX:

python -m detection.demo_cluster_recovery

Expect cluster_publication_recovery_exercise_passed. Three child processes exit before linking the manifest, after linking it, and after syncing its directory. The parent authenticates the surviving synthetic evidence and checks that a retry preserves an existing destination. Only aggregate outcomes are printed. See the publication recovery limits.

Exercise the complete two-file cluster bundle on POSIX:

python -m detection.demo_cluster_bundle_recovery

Expect cluster_bundle_recovery_exercise_passed. Abrupt child exits leave an empty, cluster-only or complete bundle. Explicit resume verifies matching survivors, preserves their bytes and inodes, publishes missing files and authenticates the complete pair. Only temporary synthetic evidence and ephemeral keys are used. The private bundle workflow explains the command, required private parent, locks and recovery limits.

Try the authenticated handoff

On POSIX, install the optional signing dependency and run the whole synthetic path:

python -m pip install -r requirements-signing.txt
python -m detection.demo_handoff

Expect handoff_exercise_passed, two parsed log lines, one emitted finding, and authenticated_and_reproduced for the valid handoff. Changed handoff bytes, changed source bytes and a revoked key are rejected. Real Ed25519 verification runs under an explicitly trusted demo policy and a fixed exercise clock. The recipient verifies after the original database and private signing key have been deleted.

The exercise now uses policy-selected signing and pins the reviewed policy bytes. It also requires rejection of retired-key signing and an incorrect pin, while allowing retired-key verification within its supplied window. These are local fixture outcomes.

The exercise generates ephemeral keys and discards all temporary files. It prints only aggregate outcomes, not keys, signatures, raw request URIs, case IDs or local paths. It does not contact a service, authenticate a real collector or prove signing time. The handoff walkthrough explains how to retain your own authorized case, select a separately trusted key and reproduce it.

Choose a workflow

GoalGuide
Read the original research overviewCase study
Read the academic paperTechnical paper
View the original slidesPresentation
Review the request flowAnalysis notes
Parse a saved log and retain a caseDetailed case workflows
Inspect node and cluster mitigation claimsMitigation example
Review formats, interfaces and limitsDetection guide
Understand legacy package locationsCompatibility notes

What works and what it establishes

AreaImplemented boundaryLimit
URI/log analysisBounded local parsing and evidence-linked findingsA match does not prove code execution
Case handlingRouting, append-only SQLite, exports and source reproductionLocal consistency does not authenticate source truth
Handoff verificationEd25519 signatures, explicit verification-key policy and retained-log reproductionPolicy trust and review clock are supplied externally
Mitigation reviewVersion/workaround and cluster evidence reviewFile presence or a signed claim does not prove a deployment fixed
Cluster manifestsShared-HMAC authentication and private publicationHMAC holders can create records; no independent signer identity

The verification-key policy handles active/retired windows and revoked keys locally. An optional independently supplied policy digest can require an exact reviewed version. It is not an authenticated directory, a fresh revocation service or enforcement on the separate raw-key signing command. See the detailed workflow before using real keys. The policy-selected signer checks an active key, review window, matching private key and retained source before publishing a detached signature. Retired keys can verify but cannot use this signing path.

Validate locally

python -m unittest discover -s tests -v
python -m unittest discover -s CVE-2022-26134-OGNL-Injection/tests -v

Signing tests require the optional dependency; skipped tests do not establish that signature verification ran. Tests use synthetic/local data, not deployed Confluence.

Safety and next work

Keep real incident logs, case records and keys private and outside Git. Use only owned or explicitly authorized inputs. No live malware or weaponized automation is part of these workflows. The tools are defensive review aids, not patch certification.

下载工具