Is gRPC implement in nuclei engine?

[nukunga]

Can i get information about gRPC or something feature like that implemented in Nuclei Engine?
if there is no feature about gRPC in Nuclei i want to develop that.

[chelalex]

Same, I hope someone will see ur question and we will get info :)

[adilburaksen]

Nuclei doesn't have native gRPC support at the moment. The built-in protocols cover http, tcp, dns, ssl, websocket, and javascript — but no gRPC DSL.

A few options depending on what you need:

Closest thing today: the javascript protocol lets you run custom JS inside nuclei. In theory you could shell out to grpcurl or use a bundled gRPC client, but it's not clean.

For actual gRPC testing tools like grpcurl or evans are much better suited — you can pipe their output into nuclei workflows or just use them standalone.

If you want to build it: the pkg/protocols directory is where each protocol lives. A gRPC protocol would need to implement the Protocol and Request interfaces there. The tcp protocol is probably the closest reference to start from.

There's an open feature request for this — worth upvoting so it gets prioritized.

[zxelzy]

Hi @nukunga, Thanks for reaching out and for your willingness to contribute!

Currently, there is no native gRPC protocol support implemented in the Nuclei engine. Users who need to test gRPC endpoints typically have to fall back on using the code protocol to execute external scripts, which isn't ideal for performance or native YAML template development.

We would absolutely love to see native gRPC support added! Since you are interested in developing this, here are a few technical pointers and architectural considerations to help you get started with the Nuclei v3 engine:

1. Codebase Integration Points
To introduce a new protocol, you will primarily need to work within these areas of the repository:

• pkg/protocols/grpc: You will need to create a new package here to encapsulate the core logic (connection handling, request execution, and response capture).
• pkg/templates/templates.go: You'll need to extend the main Template struct to parse the new grpc YAML block (e.g., adding RequestsGRPC []*grpc.Request).
• Core Interfaces: Your implementation must satisfy standard Nuclei protocol interfaces to ensure compatibility with matchers, extractors, and multi-protocol execution workflows.

2. Engineering Challenge: Payload Serialization
The most critical design decision for a gRPC protocol in Nuclei is handling Protocol Buffers. Since Nuclei templates are YAML-based, how will the engine understand the service definitions to serialize the payload?

• Will your implementation rely exclusively on gRPC Server Reflection?
• Or will you implement a mechanism to parse external .proto files referenced within the template?

3. Next Steps
Before diving deep into writing the Go code, we highly recommend opening a Feature Request / RFC (Request for Comments) detailing your proposed YAML structure for the gRPC protocol. For example:

# Proposed YAML syntax concept
id: grpc-example
info:
  name: gRPC Discovery Test
  author: yourname
  severity: info
grpc:
  - address: "{{Hostname}}:50051"
    service: "helloworld.Greeter"
    method: "SayHello"
    reflection: true # or proto-file: "path/to/service.proto"
    payload:
      name: "Nuclei"
    matchers:
      - type: word
        words:
          - "Hello Nuclei"

This will allow the core maintainers to review your proposed syntax, discuss the structural approach, and ensure your PR will seamlessly integrate into the current engine architecture.

[matheusalbarello]

Adding to what @adilburaksen and @zxelzy already covered (no native gRPC yet), how to test gRPC with Nuclei today, and a syntax proposal for the native protocol.

Testing gRPC now...

gRPC is HTTP/2 + protobuf, so the JS runtime's net library would mean reimplementing framing and protobuf by hand. The pragmatic route is the code protocol, shelling out to grpcurl (which already handles reflection + protobuf):

id: grpc-service-enum
info:
  name: gRPC service enumeration via grpcurl
  author: nukunga
  severity: info

code:
  - engine:
      - sh
    source: |
      grpcurl -plaintext {{Host}}:{{Port}} list
    matchers:
      - type: word
        words:
          - "grpc.reflection"

Run it with nuclei -code -t grpc.yaml -u target:50051 (adjust the input vars as needed). Note -code is gated behind that flag and requires template signing by design.

A syntax proposal for native grpc (re: the RFC @zxelzy mentioned)

The cleanest way to dodge the "protobuf-in-YAML" problem is to copy grpcurl's model, accept a JSON request body and marshal it via server reflection (or an optional .proto), so template authors never touch the protobuf wire format:

grpc:
  - address: "{{Host}}:{{Port}}"
    plaintext: true                      # or a tls: {} block
    method: "helloworld.Greeter/SayHello"
    request: |
      {"name": "nuclei"}                 # JSON -> protobuf via reflection
    # proto: "helloworld.proto"          # optional, for when reflection is disabled
    matchers:
      - type: word
        part: body
        words:
          - "Hello nuclei"

That keeps templates declarative, reuses the existing matchers/extractors, and only needs a reflection client + optional descriptor loader under pkg/protocols/grpc...