morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4818] [Bug] Apktool advisory context omits the Windows follow-up and 3.x regression #2504

New issue

Closed

opened 2026-10-17 21:05:52 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-17 21:05:52 +00:00

Owner

Originally created by @morluto on GitHub (Oct 17, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4818

Before submitting

Searched open/closed Apktool issues; #3438 addresses the original CVE-2024-21633 warning only.
Removed credentials and sensitive target data.

Area

Provider or capability discovery

Observed behavior

Source-derived: the selected decoder's reported version is admitted without any advisory assessment beyond the pending #3438 CVE-2024-21633 warning. That warning's upstream 2.9.2 threshold cannot describe the Windows follow-up or the later 3.x regression.

Reproduction

Source inspection at 6385ef435 and the current #3438 implementation. No real vulnerable Apktool, crafted APK, JVM or Windows runtime was executed. Executed version-policy controls establish version recognition/admission, not exploitability.

Expected behavior

Use one owner for reported-version advisory facts consumed by inspection and decode, preserving exact version spelling, unknown engine identity and downstream backport uncertainty. Disclose applicable known advisories without presenting compatibility as proof of security. Check actual patch/release provenance when source and advisory ranges conflict.

Relevant output or evidence

Windows advisory GHSA-vgwr-4w3p-xmjv: affected through 2.9.2, patched 2.9.3; platform-specific.
CVE-2026-39973: affected metadata says >=3.0.1, patched 3.0.2. That open upper range must not be blindly interpreted as every later release being affected.
Source discrepancy: upstream compare e10a045...v3.0.0 reports ahead26/behind0 and merge-base e10a0450c7afcd9462c0b76bcbff0e7428b92bdd. The v3.0.0 ResFileDecoder constructs output names and passes them to the directory writer. This identifies a review candidate; it does not independently prove exploitability or all downstream directory semantics. The 3.0.2 file also requires inspection of lower directory-writing boundaries, rather than assuming the advisory's suggested patch is its actual implementation.
REA owner/consumers: src/apktool/ApktoolConfiguration.ts, src/apktool/ApktoolProvider.ts.

Impact and scope

Missing advisory context can mislead a decoder-selection decision. Real affected-engine incidence/exploit impact in REA: NOT_ENOUGH_INFO; no vulnerable-engine test performed. Existing static local APK decoding only; no new target execution or mutation authority is proposed.

REA version

6.5.0, source 6385ef4355 plus pending #3438 changes.

Runtime and platform

Source review on macOS arm64, Node 24.18.0; Windows applicability comes from upstream advisory, not local execution.

Target and artifact context

Public upstream source/advisories and authored version strings; no real target.

Interface

CLI and MCP via shared provider (source-derived).

Earliest failure stage

Provider readiness and completed resource Evidence.

Typed outcome or recovery expected

Advisory-specific limitations with provenance and uncertainty, separate from availability and successful projection. Validate release/prerelease/build boundaries, host applicability, raw version retention, and both operations through CLI/MCP.

Analysis or suspected cause

A single minimum fixed version is insufficient for multiple advisory ranges/platforms. Resolve the actual range facts before integration; downstream version labels do not prove engine contents or patch status.

Additional context

#3438 remains independently actionable for its original advisory. DeepWiki could not reconcile the release history; primary source and advisory metadata were checked directly. No new vulnerability in Apktool is claimed.

Originally created by @morluto on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4818 ### Before submitting - [x] Searched open/closed Apktool issues; #3438 addresses the original CVE-2024-21633 warning only. - [x] Removed credentials and sensitive target data. ### Area Provider or capability discovery ### Observed behavior Source-derived: the selected decoder's reported version is admitted without any advisory assessment beyond the pending #3438 CVE-2024-21633 warning. That warning's upstream 2.9.2 threshold cannot describe the Windows follow-up or the later 3.x regression. ### Reproduction Source inspection at 6385ef435 and the current #3438 implementation. No real vulnerable Apktool, crafted APK, JVM or Windows runtime was executed. Executed version-policy controls establish version recognition/admission, not exploitability. ### Expected behavior Use one owner for reported-version advisory facts consumed by inspection and decode, preserving exact version spelling, unknown engine identity and downstream backport uncertainty. Disclose applicable known advisories without presenting compatibility as proof of security. Check actual patch/release provenance when source and advisory ranges conflict. ### Relevant output or evidence - [Windows advisory GHSA-vgwr-4w3p-xmjv](https://github.com/iBotPeaches/Apktool/security/advisories/GHSA-vgwr-4w3p-xmjv): affected through 2.9.2, patched 2.9.3; platform-specific. - [CVE-2026-39973](https://github.com/iBotPeaches/Apktool/security/advisories/GHSA-m8mh-x359-vm8m): affected metadata says `>=3.0.1`, patched 3.0.2. That open upper range must not be blindly interpreted as every later release being affected. - Source discrepancy: upstream compare `e10a045...v3.0.0` reports ahead26/behind0 and merge-base e10a0450c7afcd9462c0b76bcbff0e7428b92bdd. The [v3.0.0 ResFileDecoder](https://github.com/iBotPeaches/Apktool/blob/v3.0.0/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/decoder/ResFileDecoder.java) constructs output names and passes them to the directory writer. This identifies a review candidate; it does not independently prove exploitability or all downstream directory semantics. The 3.0.2 file also requires inspection of lower directory-writing boundaries, rather than assuming the advisory's suggested patch is its actual implementation. - REA owner/consumers: `src/apktool/ApktoolConfiguration.ts`, `src/apktool/ApktoolProvider.ts`. ### Impact and scope Missing advisory context can mislead a decoder-selection decision. Real affected-engine incidence/exploit impact in REA: NOT_ENOUGH_INFO; no vulnerable-engine test performed. Existing static local APK decoding only; no new target execution or mutation authority is proposed. ### REA version 6.5.0, source 6385ef4355d7a794b3154ee38529cbddee583336 plus pending #3438 changes. ### Runtime and platform Source review on macOS arm64, Node 24.18.0; Windows applicability comes from upstream advisory, not local execution. ### Target and artifact context Public upstream source/advisories and authored version strings; no real target. ### Interface CLI and MCP via shared provider (source-derived). ### Earliest failure stage Provider readiness and completed resource Evidence. ### Typed outcome or recovery expected Advisory-specific limitations with provenance and uncertainty, separate from availability and successful projection. Validate release/prerelease/build boundaries, host applicability, raw version retention, and both operations through CLI/MCP. ### Analysis or suspected cause A single minimum fixed version is insufficient for multiple advisory ranges/platforms. Resolve the actual range facts before integration; downstream version labels do not prove engine contents or patch status. ### Additional context #3438 remains independently actionable for its original advisory. DeepWiki could not reconcile the release history; primary source and advisory metadata were checked directly. No new vulnerability in Apktool is claimed.

bsakaguchi

2026-10-17 21:05:52 +00:00

closed this issue
added the
bug
label

bsakaguchi commented

2026-10-17 21:05:55 +00:00

Author

Owner

@morluto commented on GitHub (Oct 17, 2026):

Fixed in d38f09969.

The parsed version owner now receives the selected host. Both inspection and decode disclose the Windows follow-up before 2.9.3 on Windows, and the 3.0.x type-name validation window before 3.0.2. Shared formatting preserves the original CVE warning, reported spelling, prerelease semantics, and downstream dirty-release handling. Completed warning Evidence survives late cancellation and failed cleanup.

Research resolved the producing boundary: upstream 65dd848 validates ResTypeSpec names and is present in tagged 3.0.2. Tagged 3.0.0 lacks that check; its output producer passes the type name into the directory writer. Inclusion of 3.0.0 is explicitly source-derived in both its warning and docs, distinct from the advisory's 3.0.1 metadata. The open-ended affected metadata is bounded by the stated patched release. Prereleases are conservative version guidance, not a claim that their exact engine bytes were inspected.

Validation: 222 focused tests across 15 files, static/docs/commit/push checks; 16 controls fail on the clean previous commit; two source reviews clear. Six actual built CLI controls and twelve stdio MCP workflows used tiny authored launchers. Full discovery plus inspection/decode preserves control-version Evidence/catalog; the warning case changes only limitations and Evidence IDs. Text/structured equality, raw version, metadata, digest, strings, count and coverage checked. Measured source hashes and committed AST parity verified after formatting.

Warm medians baseline/candidate (two alternating repeats per build plus separate first processes): 3.0.0 workflow elapsed 3.387/3.158s, CPU 4.506/4.133s, sampled family RSS 1350/1272 MB; 3.0.2 control elapsed 3.010/2.922s, CPU 4.204/3.912s, RSS 1354/1264 MB. Full discovery plus two replies estimates: cl100k 804842→805326 for deliberate disclosures; control 804840 unchanged. No speedup claim; caches not flushed, PPID sampling can miss transient/reparented processes.

No real Apktool/JVM, native Windows, exploit/crafted APK, true cold, large-inventory or whole-agent-token verification. Host/version matching does not establish child engine contents, execution platform, downstream backports or overall safety; absence of a warning makes no such claim. No runtime advisory fetch or new target authority. Heavy profiling/stress remained stopped.

DeepWiki mixed current-tree and historical details and did not establish the patch history; primary tagged source and commit history were used instead.

@morluto commented on GitHub (Oct 17, 2026): Fixed in d38f09969. The parsed version owner now receives the selected host. Both inspection and decode disclose the Windows follow-up before 2.9.3 on Windows, and the 3.0.x type-name validation window before 3.0.2. Shared formatting preserves the original CVE warning, reported spelling, prerelease semantics, and downstream dirty-release handling. Completed warning Evidence survives late cancellation and failed cleanup. Research resolved the producing boundary: upstream [65dd848](https://github.com/iBotPeaches/Apktool/commit/65dd8480dfcb63068562ffaa527f71bb0a9f772c) validates `ResTypeSpec` names and is present in tagged 3.0.2. [Tagged 3.0.0](https://github.com/iBotPeaches/Apktool/blob/f770b39e425af4fa6ac4ca1e9ea6c4824339c6d3/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/table/ResTypeSpec.java) lacks that check; its output producer passes the type name into the directory writer. Inclusion of 3.0.0 is explicitly source-derived in both its warning and docs, distinct from the advisory's 3.0.1 metadata. The open-ended affected metadata is bounded by the stated patched release. Prereleases are conservative version guidance, not a claim that their exact engine bytes were inspected. Validation: 222 focused tests across 15 files, static/docs/commit/push checks; 16 controls fail on the clean previous commit; two source reviews clear. Six actual built CLI controls and twelve stdio MCP workflows used tiny authored launchers. Full discovery plus inspection/decode preserves control-version Evidence/catalog; the warning case changes only limitations and Evidence IDs. Text/structured equality, raw version, metadata, digest, strings, count and coverage checked. Measured source hashes and committed AST parity verified after formatting. Warm medians baseline/candidate (two alternating repeats per build plus separate first processes): 3.0.0 workflow elapsed 3.387/3.158s, CPU 4.506/4.133s, sampled family RSS 1350/1272 MB; 3.0.2 control elapsed 3.010/2.922s, CPU 4.204/3.912s, RSS 1354/1264 MB. Full discovery plus two replies estimates: cl100k 804842→805326 for deliberate disclosures; control 804840 unchanged. No speedup claim; caches not flushed, PPID sampling can miss transient/reparented processes. No real Apktool/JVM, native Windows, exploit/crafted APK, true cold, large-inventory or whole-agent-token verification. Host/version matching does not establish child engine contents, execution platform, downstream backports or overall safety; absence of a warning makes no such claim. No runtime advisory fetch or new target authority. Heavy profiling/stress remained stopped. DeepWiki mixed current-tree and historical details and did not establish the patch history; primary tagged source and commit history were used instead.

bsakaguchi referenced this issue

2026-10-31 01:05:25 +00:00

[PR #2504] [CLOSED] fix(browser): honor service worker allow policy in attached scenarios #5281

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#2504

No description provided.

Rows
Columns