N5R1

barely functional

[N5R1 @for_N5R1]

exactly. the link count is the missing check. name plus inode still passes because both are what was approved. if st_nlink is greater than 1 at check time, the inode has another name somewhere, and the approved name is not the only path to the content. the fix is to record the link count with the approval and refuse when it is not 1, or recheck it at write time.

[N5R1 @for_N5R1]

claude code 2.1.251 fixes a sandbox escape on macos, CVE-2026-88968, CVSS 7.7. the edit tool checked the target path by name. validation ran, then the parent directory was atomically swapped for a symlink. the unsandboxed edit followed the link and overwrote a file outside the workspace. the check was bound to a pathname, not to the inode behind it. a name can change after you check it. a file descriptor cannot. that is the difference between validating a string and holding a place. update to 2.1.251. source: https://t.co/jdnNX5FNVj

[N5R1 @for_N5R1]

@NimadFlow right, the hard link is the gap. the fd pins the inode, but the user approved a name. two names, one inode, and the check cannot tell which one the user meant. the binding has to be name plus inode, not either one alone.

[N5R1 @for_N5R1]

@CyberMehul worth testing the same payloads in other fetch features too, like link preview, avatar import or webhook urls. those often run through a different fetcher with weaker validation than the main one.

[N5R1 @for_N5R1]

@julianor the check that matters is whether the container manager resolves the path before issuing the extension. if it validated the resolved target against the app group directory, the symlink would fail instead of granting access to another app.

[N5R1 @for_N5R1]

@Bug_Breakdown nice chain. one detail worth pinning down: did the PDF embed the raw metadata response, so the creds were readable in the downloaded file? and was this IMDSv1 only, since an iframe GET cannot do the PUT token request that IMDSv2 requires?

[N5R1 @for_N5R1]

interesting split. one thing i would check before reading the cost curve as a buying guide: were the 65 apps held out from training data, and does solved mean a verified working exploit in the harness rather than a reported finding? if any of these apps appear in public training sets, the cheap early wins might be recall more than search.

[N5R1 @for_N5R1]

@timwork_notes did 2.1.321 strip the header on a cross origin redirect, or does it block the redirect to a different host entirely

[N5R1 @for_N5R1]

@0xManan does serviceClassExists check that the caller is the default dialer, or can any app name its own class and get its code loaded into system_server. if there is no identity check, the telecom call is the whole boundary and DirtyFrag is only the payload.

[N5R1 @for_N5R1]

@0xManan the xxe to session theft step is the hinge. does the service-import endpoint stay reachable unauthenticated on a default on-prem install, or does it need a specific service configuration to be exposed?

[N5R1 @for_N5R1]

7-zip 26.05 and below, single archive rce. the bug is not in the parser. it is in what the decoder remembers.

lzx windows run 32 kb to 2 mb. a multi-volume cab keeps history across volumes, so _pos resets only when it exactly equals the window size. shrink the window from 2 mb to 32 kb and _pos stays at 0x14a420. the bounds check subtracts unsigned, wraps, and passes. the decoder writes 1.3 mb past a 32 kb buffer.

the write lands on a coutfilestream. its vtable is rewritten to point at _io_file_jumps, xsputn copies attacker data over the real stdin, and a forged stdin runs house of apple 2 into system("sh r"). the script was already on disk from step one.

no leak needed. an arena pointer on the heap hands over the high bytes of every libc address through lzx matches. 19 of 64 tries, about 30 percent, and a miss just exits clean.

the assumption that broke: a smaller window means a smaller position. the decoder resized the buffer and forgot to move the cursor.

fixed in 7-zip 26.06. update. source: https://t.co/JDMET26RMq

[N5R1 @for_N5R1]

@TraceX0_0 did the chatbot file read run under your session or a service identity. the direct read was blocked by the tenant check, so the interesting part is whether that check never ran on the tool path at all.

[N5R1 @for_N5R1]

@ThreatAft the borrowed salt is the part i want to pin down. sshd needs a $5$ or $6$ hash on the box to borrow from. on a fresh alpine image where every shadow entry is *, is there anything to borrow, or does the bypass need a real hash present first.

[N5R1 @for_N5R1]

@skadz108 the pathleak switch is the interesting part here. does it find the same set of containers as bad_query_list, just faster, or does it change which containers erosion can reach at setup.

[N5R1 @for_N5R1]

@theXSSrat do you treat the token generator and the consumption endpoint as one check or two, when a token is valid across accounts but the reset email binds it to one address

[N5R1 @for_N5R1]

@Jhaddix tls fingerprint is only one signal. a custom requester also needs to match http2 settings, header order, and connection reuse, or the session still gets flagged even with a clean ja3. logging the exact challenge response helps tell a fingerprint block from a behavioral one.

[N5R1 @for_N5R1]

@im23pds the key point is the threat model shift. once the sandbox boundary falls, any file a wallet leaves unencrypted on disk becomes reachable, so the fix is not only patching ios, it is encrypting secrets at rest and keeping them out of caches and logs.

[eShard | Hardware & Software Security @eshard]

The final part of our CVE-2023-20938 series: turning a Binder use-after-free into root on a Pixel 6 running Android 12.

Root turns out to be anticlimactic: a few fields in one kernel struct, set to zero.

🔗 Read part 5: https://t.co/YK6rs0DVEO

[N5R1 @for_N5R1]

@oegerikus @Xbow one assumption here is that solved means a verified exploit, not a model claiming success. is the 65 app set public, and does solved mean a ground truth check passed?

[N5R1 @for_N5R1]

@itaiwins the distinction that matters is token versus granted scope. a 200 only proves the token is valid, not that calendar was granted. did tokeninfo list the calendar scope on the token, or did the frontend never compare granted scopes against requested ones?