T06 · System Persistence
- Location
references/heartbeat_task.md:7- Finding
Unbounded Recurring Task Persistently Polls Candidate Communications
- Content
View full analysis
Vulnerability Details
File Location:
references/heartbeat_task.md, lines 7–18 and 29–37;references/workflow-schedule-interview.md, lines 48–56
Vulnerability Type: Unbounded cross-session scheduled task
Risk Level: HighVulnerable Code
markdown ## 创建心跳任务 使用 **CronCreate 工具**： - **cron**: `*/30 * * * *` - **recurring**: `true` - **prompt**:用 opencli boss chatmsg 查看最新消息，判断 <候选人姓名> 是否有新回复。 如有实质性回复（同意/拒绝/给出时间）则执行约面试流程 Step 5： 查看日程，然后直接在当前对话中告知用户候选人的回复内容，并提供 2-3 个候选时间请用户确认。 否则静默等待。
text markdown ## 终止心跳任务 面试约好后，执行：CronDelete <job_id>
text → job_id 通过 CronList 查询获得。The interview workflow independently instructs creation of the same persistent task:
markdown ### Step 4：启动 30 分钟心跳检测 执行以下指令创建定时任务，每 30 分钟检查候选人是否回复： > 使用 CronCreate 工具，cron 表达式 `*/30 * * * *`，prompt 内容： > > "用 opencli boss chatmsg `<uid>` 查看最新消息，判断候选人是否有新回复。如果有明确的回复（同意/拒绝/给出时间），执行约面试流程的 Step 5。如果无新回复，静默等待下次检查。"Technical Analysis
The Skill directs the agent to install a recurring Cron task that survives the initiating interaction and invokes authenticated Boss Zhipin access every 30 minutes. The task has no expiration time, maximum retry count, or general cleanup handler.
The only documented deletion condition is after an interview has successfully been scheduled. Cleanup is not specified when:
- The candidate refuses the interview.
- The candidate never responds.
- The user cancels or abandons the process.
- A command or workflow step fails.
- The task reaches a reasonable timeout.
- The candidate gives a substantive response that does not result in a scheduled interview.
The workflow also retrieves the task identifier through a global
CronListoperation rather than requiring thejob_idreturned byCronCreateto be stored against the specific candidate and workflow. This can make reliable ownership and deletion difficult when several tasks are active.Because the scheduled prompt accesses an authenticated co ...[truncated 1672 chars]
- Remediation
View remediation
Remediation Suggestions
-
Bound the task lifetime
- Set a strict expiration, such as 24–48 hours.
- Enforce a maximum number of polling attempts.
- Prefer a scheduler that supports automatic expiration.
-
Implement complete cleanup
- Delete the task when the candidate accepts, rejects, or provides a conclusive response.
- Delete it when the user cancels the workflow.
- Delete it after timeout, unrecoverable errors, or successful scheduling.
- Use a
finally-style cleanup path where supported.
-
Track task ownership
- Capture the exact
job_idreturned byCronCreate. - Associate it with the candidate UID and interview workflow instance.
- Do not depend on global
CronListoutput to infer which task should be deleted. - Prevent duplicate active polling tasks for the same candidate.
- Capture the exact
-
Require informed user authorization
- Tell the user that a cross-session recurring task will be created.
- Obtain explicit confirmation before installing it.
- Provide a simple command to list and cancel recruitment polling tasks.
-
Reduce scheduled-task authority
- Restrict the task to checking and reporting status.
- Require fresh user approval before sending messages, modifying records, or creating calendar events.
- Ensure the scheduled prompt cannot broaden its scope based on untrusted candidate message content.
-
Prefer event-driven processing
- Use an official message notification or webhook mechanism where available.
- If polling is unavoidable, use the lowest practical frequency and store only the minimum state required to detect a new response.
-