EdgeFuzz: A Middleware-Based Security Testing Tool for Vulnerability

Discovery in Distributed Computing Applications

Mishaal Ahmed

1 a

and Muhammad Ajmal Naz

2 b

Dipartimento di Matematica e Fisica, Universit

a di Campania Luigi Vanvitelli, Caserta, Italy

Dipartimento di Elettronica e Telecomunicazioni, Politecnico di Torino, Turin, Italy

Keywords:

Fuzzing, Security Testing, Distributed Computing.

Abstract:

Distributed computing faces many security challenges due to the nature of the distribution of connecting nodes.

Fuzz testing has become a popular automated tool for ﬁnding software system bugs and vulnerabilities in dis-

tributed environments. Distributed systems are characterized by various components spread across different

network nodes. Such systems exhibit intrinsic complexities due to scalability, coordinated concurrency, and

heterogeneity. Implementing fuzzing in such environments introduces additional challenges, such as manag-

ing communication and synchronization between distributed nodes to ensure that fuzzing tasks are executed

promptly and coherently. In this paper, we proposed a novel EdgeFuzz Fuzzer to discover vulnerabilities in the

server nodes of the distributed network through middleware-based fuzzing. EdgeFuzz is a black-box Fuzzer

that modiﬁes incoming client requests and sends them to the server while monitoring if a crash has occurred.

We employed EdgeFuzz to test distributed networking tools and found server-side code vulnerabilities in se-

lected applications.

1 INTRODUCTION

Finding vulnerabilities in software systems is crucial

to ensure safety. Traditional testing techniques im-

pose limitations in discovering vulnerabilities due to

limited coverage and dependence on manually crafted

predeﬁned test cases that are prone to miss edge

cases that can be exploited (Takanen et al., 2018).

Moreover, traditional testing techniques fail to sim-

ulate complex dynamic interactions in modern dis-

tributed systems due to their scalability and dynamic

nature (Borrello et al., 2024).

In recent years, fuzz testing(fuzzing) has become

quite popular (Zhao et al., 2024). It eases the process

of testing through automation (Man

es et al., 2019).

Fuzzing facilitates generating thousands of test cases

per second without any manual intervention, offering

a more resourceful way of discovering vulnerabili-

ties (Yao et al., 2024). Fuzzing can handle complex

and dynamic interaction patterns as it adjusts inputs in

response to the system’s behavior. Notably, once the

fuzzing has been set up, it can easily be adapted and

scaled, which is cost-effective. The core component

of a Fuzzer is the harness that generates test cases,

https://orcid.org/0000-0003-2875-7438

https://orcid.org/0009-0005-2264-1209

while the crash monitoring component helps log vul-

nerabilities, as shown in Figure 1.

Figure 1: Schematic Representation of a Fuzzer.

Distributed computing has a complex decentral-

ized architecture that spans across multiple network

nodes. To ensure synchronization and consistent

communication, protocols are employed, introducing

complexity in these systems (STEEN and TANEN-

BAUM, 2017).

Fuzzing a distributed system poses a challenge to

maintaining the states of the nodes and adds a new

layer of complexity because issues like packet re-

ordering and variable latency are likely to occur fol-

lowing protocols like TCP. Injecting randomization in

network requests disrupts the expected timing and se-

quence of message exchanges (Anderson, 2020). This

approach requires us to generate precise test cases to

challenge the system in a robust manner by injecting

malformed inputs while navigating the random nature

Ahmed, M. and Naz, M. A.

EdgeFuzz: A Middleware-Based Security Testing Tool for Vulnerability Discovery in Distributed Computing Applications.

DOI: 10.5220/0013521600003979

In Proceedings of the 22nd International Conference on Security and Cryptography (SECRYPT 2025), pages 619-625

ISBN: 978-989-758-760-3; ISSN: 2184-7711

619

of the network. Moreover, the ability of a network-

ing protocol to exchange information from around the

globe is prone to remote execution attacks (Biswas

et al., 2018). A malicious user does not need phys-

ical access to the actual machine. For example, the

implementation of SSL/TLS protocol incorporated a

security ﬂaw known as Heartbleed in OpenSSL (Du-

rumeric et al., 2014).

Several challenges are faced by state-of-the-art

fuzzing techniques. Firstly, the network protocols

are stateful and the server accepts a proper structure

of request in a deﬁned sequence. The acknowledge-

ment of the server depends on both the present in-

ternal state controlled by previous requests and the

request on hand. The state-of-the-art Fuzzers such

as AFL, HongFuzz, and Jazzer are not applicable to

distributed systems because of their inability to han-

dle the state information (Pham et al., 2019). These

Fuzzers only handle stateless programs. Current so-

lutions on fuzzing protocols rely on writing test har-

ness for program states or linking message sequences

in ﬁles for mutation (Zhang et al., 2023). Both ap-

proaches have their own set of drawbacks such as

unit testing is unable to systematically test state tran-

sitions, requiring manual effort, and it is not applica-

ble for end-to-end fuzzing without source code. Sec-

ondly, the lack of state transition produces many in-

valid sequences of messages that are likely to be re-

jected by the server since it operates on a deﬁned

protocol and structure. The workaround technique is

stateful black-box fuzzing (SBF). These Fuzzers tra-

verse protocols and leverage data models to generate

syntactically valid messages accepted by the proto-

col state machine. Their viability relies upon manu-

ally produced models based on protocol speciﬁcations

which may not precisely address the executed proto-

col.

A middleware-based Fuzzer addresses this chal-

lenge by intercepting and manipulating the interac-

tion between network nodes. This strategy takes

into account the injection of malicious information,

thereby stimulating real-world attacks and revealing

hidden vulnerabilities. By improving the constancy

of security tests without deep system integration, a

middleware-based Fuzzer emerges as a vital method

for enhancing and securing distributed systems. In

this paper, we propose a novel technique to fuzz dis-

tributed systems through middleware-based fuzzing.

To the best of our knowledge, there is no current im-

plementation of a Fuzzer based on this technique.

Our contributions are given below:

• We introduce EdgeFuzz, a novel black-box

Fuzzer that intercepts client requests, mutates

them using bit ﬂipping based on randomization,

sends the modiﬁed request to the server, and mon-

itors for server crashes.

• We present optimizations aimed to enhance the

speed of the fuzzing, thereby using lightweight

mechanisms for harness, input generation, and

crash monitoring, resulting in a signiﬁcant reduc-

tion in the time required to conduct comprehen-

sive security tests

2 RELATED WORK

Past studies symbolized the complexity of testing dis-

tributed systems and highlighted crucial challenges

imposed by the cloud computing environments based

on dynamic nature, robust synchronization, and com-

munication mechanisms and emphasized the difﬁ-

culties related to scalability evaluation and perfor-

mance testing (Jiang et al., 2024). For instance,

Gao et al. (Gao et al., 2011) highlighted the key chal-

lenges based on difﬁculties in scalability evaluation

and performance testing mainly because of the pre-

conﬁgured system resources. Likewise, Ge et al. (Ge

et al., 2017) outlined design issues inherent to dis-

tributed systems.

Current research trends on fuzzing have been

mostly carried out on grey-box fuzzing because of

its features like code coverage, code-aware input

structure, and use of interesting inputs to repli-

cate identiﬁed vulnerabilities (Srivastava and Payer,

2021) (Liang et al., 2022). However, for code cover-

age, the target must be instrumented to track the map-

per’s bitmap entries, which requires modiﬁcations in

the existing code, slowing down the fuzzing process.

Similarly, crafting specialized inputs requires a de-

tailed knowledge of the target system. Also, the

use of grammar rules or record and replay can be

time-consuming. In contrast, we present a black-box

Fuzzer, that keeps track of the inputs that generated

the vulnerability. Moreover, it randomizes the re-

quests and learns from the client about the type of

request being sent, which means it uses structured in-

puts by using buffers but not grammar.

Similarly, several networking-based black-box

Fuzzers have been developed, such as Sulley, Boo-

Fuzz, Peach, and beSTORM (Munea et al., 2016).

In these Fuzzers, inputs are manually crafted proto-

col speciﬁcations. In contrast, EdgeFuzz automati-

cally fetches the input structure of the request. Craft-

ing manual requests requires a lot of effort, and it’s

error-prone. A more efﬁcient black-box technique has

been proposed by Fan et al. (Fan and Chang, 2018)

to create the request structure based on a given cor-

pus by reverse engineering the networking protocol

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

620

during the fuzzing, however, it required deep integra-

tion of the fuzzing harness. Interestingly, in white-

box approaches, the requests are crafted by actively

exploring the protocol implementation, but it requires

source code (Tsankov et al., 2012). For example,

a dynamic analysis method based on symbolic exe-

cution and tainting can be used to obtain the request

design from the protocol implementation (Caballero

et al., 2007). In addition, the technique presented

by Gascon et al. (Gascon et al., 2015) infers proto-

col state machines from request structures, while ac-

tive learning methods dynamically query protocol im-

plementations with generated requests (De Ruiter and

Poll, 2015) (Ba et al., 2022). In contrast, EdgeFuzz

does not require any request templates or manually

constructed requests. It operates on command line in-

struction that is initially entered by the user and then

automatically captured by the Fuzzer based on the tar-

get application.

Recently, AFLNET has been introduced, which

extends AFL for stateful applications. However, it re-

quires a well-designed initial seed input; otherwise,

it misses critical bugs (Pham et al., 2020). More-

over, the conﬁguration of the Fuzzer itself, along with

the server code modiﬁcation and the use of external

tools, increases the complexity of using AFLNET. It

is essential to have source code to make modiﬁca-

tions in the server code. If there is no code avail-

able, then fuzzing is inefﬁcient. Notably, AFLNET is

a coverage-based Fuzzer which requires instrument-

ing the server code. Code coverage is a great feature,

but impacts performance. In contrast, EdgeFuzz is

designed to provide an agile solution.

3 EdgeFuzz METHODOLOGY

We present EdgeFuzz, to test servers in distributed

systems based on fuzzing message requests rather

than protocols in a stateful manner. The architec-

ture of EdgeFuzz is shown in Figure 2. There are

two dashed boxes on the sides, representing the in-

ternal mechanisms of the fuzzer, including packet in-

terception, mutation, and forwarding. In particular,

these boxes do not correspond to separate compo-

nents on the server or client side. There are three

core components of the EdgeFuzz described as fol-

lows: Request Handler manages incoming packets

and requests; Harness is the fuzzing engine that in-

tercepts and mutates incoming requests before for-

warding them to the server; and Crash Monitor keeps

track of errors, log crashes, and stores interesting re-

quests/packets for further analysis.

The primary goal of EdgeFuzz is to address the

aforementioned limitations. Unlike AFLNET, our

Fuzzer is a black-box-based random Fuzzer. It modi-

ﬁes the requests sent by the client to the server and

provides feedback on discovered vulnerabilities. It

modiﬁes the request header or data by bit ﬂipping a

random byte. EdgeFuzz is simple to set up and be-

haves as a node in the network and can be employed

in various scenarios as a network to test the server or

the client. It is a user-friendly Fuzzer, even for peo-

ple who don’t have advanced knowledge of network

security. The client node sends a request to the server

while the EdgeFuzz intercepts that request and initi-

ates fuzzing based on the given request and monitors

if a crash occurs. The log of the crash is displayed on

the screen.

We named our Fuzzer “EdgeFuzz” because it

serves as a middleware fuzzer between two nodes of

a distributed client-server application, intercepting re-

quests, and working as an intermediary between client

and server nodes. The base functionality is to mutate

requests sent by the client to the server. EdgeFuzz

mutates a given message request by performing a bit-

ﬂipping random byte from the message sequence. We

tested our Fuzzer based on HTTP requests with the

underlying protocol as TCP based on different open-

source applications.

By monitoring the response time, error codes and

crash reports, EdgeFuzz detects server failures. The

mutated request is logged upon receiving no response

or in the event of a timeout. With the increase in

complexity of distributed environments, later versions

will probably expose more sophisticated correlation

mechanisms to recognize the crashes caused by se-

quences of malformed messages, allowing the fuzzer

to correlate the failures across nodes and better iden-

tify patterns.

Algorithm 1: EdgeFuzz Algorithm.

In the given Algorithm 1, we provide an overview

of how the system, from a high-level perspective, is

Data: Initial request: in req

Result: Logged responses and errors

while ¬ exit condition do

Generate a new request:

new req ← req mutation(in req)

Process request:

process request(new req)

Send request: send to server(new req)

response ← receive response()

Log response: log response(response)

error Log error: log error(new req, error)

if critical error detected(error) then

Break execution

end

EdgeFuzz: A Middleware-Based Security Testing Tool for Vulnerability Discovery in Distributed Computing Applications

621

Figure 2: Overview of the EdgeFuzz Architecture.

working. Notably, EdgeFuzz does not require any ex-

ternal tool such as Wireshark. EdgeFuzz, as a black-

box Fuzzer, is faster than grey-box Fuzzers. So far,

EdgeFuzz has been limited to fuzz TCP and HTTP-

based distributed systems; nevertheless, in the future,

we intend to extend its features.

4 IMPLEMENTATION DETAILS

We implemented EdgeFuzz in the C programming

language. To facilitate network communication,

which is not available in famous Fuzzers like AFL,

Hongfuzz, and Jazzer, we employed the use of socket

programming to facilitate communication among the

clients and the server. We implemented two chan-

nels to send and receive responses from the client and

the server. When the response is received, it provides

feedback if a crash occurs. We have used the pthread

library available in the C programming language to

handle requests, connections, polling, queuing, demo-

nization, mutation, and error management. Each of

these threads is responsible for properly synchroniz-

ing EdgeFuzz with the client and the server. Other-

wise, various issues may arise, for instance, the drop-

ping of the connection if a new request is received be-

fore the response is sent and acknowledged. Initially,

the input request is given by the user, and the ports are

required to be deﬁned to connect the EdgeFuzz with

the client and the server. We implemented a request

randomization method to mutate the header and the

body of the request being sent on a TCP connection

protocol.

We employed the use of buffers to send and re-

ceive the request/response. The responses are re-

ceived in the same sequence as the way they are sent

to the server. The mutator randomly selects a byte

in the message request and performs randomization

in that byte. There are two targets: the context of

the request, either the header or the body; and the

byte to be replaced. The header request structure is

shown in Figure 3. The current version of EdgeFuzz

is based on application-level packets. EdgeFuzz ap-

plies bit-ﬂipping mutations in real time, but only to

higher-layer packets for application level protocols

(i.e., applying mutations only to the headers and body

within TCP and/or HTTP messages). It does not mod-

ify headers in the underlying lower layers, such as the

header in IP or Internet Layer. This guarantees that

only upper-level data, request/response HTTP head-

ers, and body content, are mutated, so underlying

transport and headers can remain unchanged.

Figure 3: Request Format.

Moreover, we implemented a mechanism to re-

tain a pool of requests sent by the clients. EdgeFuzz

fetches the requests from this pool, which is based

on a queue, and performs fuzzing on these requests.

We have implemented a byte-level operation for the

mutator based on selecting a random byte within the

request and bit-ﬂipping the byte. During the fuzzing

process if the error logging module indicates a critical

bug, then the request is saved as an interesting input

for debugging purposes. In addition, the state of the

server is also logged for each request using a buffer.

The internal architecture of EdgeFuzz is shown in

Figure 4.

Figure 4: EdgeFuzz Detailed Architecture.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

622

4.1 Evaluation Setup

We performed tests on the two Dell PowerEdge R760

servers connected using a SONiC-based white box

network switch. We used Ubuntu 22.04.1-LTS as

the OS. We create separate virtual machines for each

node of the network using QEMU/KVM. To analyze

the packet loss, we have utilized Wireshark.

We employed EdgeFuzz in three scenarios for the

experiments. Firstly, in a single client and server sce-

nario where the client sends requests to the server, as

shown in Figure 5. We mainly tested the selected ap-

plications with one client, one server, and the Fuzzer

in the middle.

Figure 5: Fuzzing with EdgeFuzz (Scenario 1).

Secondly, we employed EdgeFuzz using multi-

ple clients and a single server scenario where var-

ious clients send requests to a single server testing

as shown in Figure 6. EdgeFuzz was able to grace-

fully handle multiple requests but it slowed down the

amount of requests being fuzzed.

Figure 6: Fuzzing with EdgeFuzz (Scenario 2).

Finally, we performed tests based on multiple

clients and multiple instances of EdgeFuzz with one

server. In this scenario, we employed four EdgeFuzz

instances for a single server handling a lot of clients

as shown in Figure 7. Interestingly, the efﬁciency of

EdgeFuzz did not degrade much.

Notably, various other scenarios are applicable,

which may include multiple servers. It is worth not-

ing that AFLNET is not suitable for scenarios that in-

volve multiple instances of a fuzzer. This is mainly

due to the complexity of setting up AFLNET on dif-

ferent nodes, which involves conﬁguring the initial

seed, changing server code responses, and conﬁgur-

ing AFLNET itself. These factors limit the usability

of AFLNET in such scenarios. To compare our Edge-

Fuzz with the state-of-the-art, we used scenario 1 for

all the applications because only EdgeFuzz supports

running multiple instances (e.g., four), while other

fuzzers do not support this feature and are almost im-

Figure 7: Fuzzing with EdgeFuzz (Scenario 3).

possible to set up in such scenarios with multiple in-

stances.

5 RESULTS AND DISCUSSION

We employed EdgeFuzz to test three tools i.e. Tool 1

(T., 2020), Tool 2 (Thorpe, 2021), and Tool 3 (Juan

et al., 2020), which are open-source application tools

that are available on GitHub. We selected these tools

because emulate distributed systems scenarios and are

based on TCP. We utilized scenario 1 to compare the

results with state-of-the-art Fuzzers.

We evaluated the Fuzzers on the selected tools

based on server shutdown. We found assertions raised

by the server where the server crashes because of an

unknown request since the EdgeFuzz is able to ran-

domize the request’s header and body. Any change in

the header can cause the packet to become unknown.

Moreover, we performed tests based on AFLNET on

the same tool. However, it was not able to replicate a

similar crash.

Table 1: Results of Fuzzing with Selected Fuzzers.

Tool Time to Error Error

Type

Peach BOOFUZZ AFLNET EdgeFuzz

Tool 1 06m 07s 10m 05s 03m 15s 53s

Assertion-

Based

EXIT

FAILURE

Tool 2 03m 02s 15m 39s 05m 06s 02m 43s

Tool 3 08m 29s 17m 44s 05m 33s 01m 41s

The results of the fuzzing tests we ran for different

distributed application emulators showed that Edge-

Fuzz remained the fastest among the other Fuzzers in

terms of ﬁnding assertions leading to server failure, as

displayed in Table 1. Experiments were repeated 10

EdgeFuzz: A Middleware-Based Security Testing Tool for Vulnerability Discovery in Distributed Computing Applications

623

times to provide statistics on the times measured. We

also share the list of some issues that servers cannot

gracefully handle are shown in Table 2.

Table 2: Details of Code Issues Found Through Fuzzing.

Tool Issue Details

Tool 1

Assertion: Unknown

Command Type. Exit

failure

Server not able to grace-

fully handle the assertion in

message.c leading to server

shutdown

Assertion failure occurs

when the conditions are

not met in server code

Assertion m

dst

→ req

size

≥

opts → resp

size

failed.

Aborted (core dumped)

Tool 2

Unhandled Exception:

Out of bounds access

Memory exhaustion is not

being gracefully handled

Issue in Worker-

Datagra-Forwarding-

Script

Last 4 bytes of the packet

are being considered as IP

which requires to be ﬁxed

Tool 3 Inﬁnite Loop in method

SimpleRequest

Source, RequestSource,

PeriodicSource

Fuzzed requests manipulat-

ing timing ‘delta t’ caused

repeated failures leading to

server shutdown

Table 3: Comparison of Fuzzing Scenarios.

Scenario

Description

Total

Requests

Processed

Unique Vul-

nerabilities

Identiﬁed

Resource

Usage (CPU,

Memory)

1 Client, 1

Fuzzer, 1

Server

10,357 2 Low CPU

usage, low

memory

Many Clients,

1 Fuzzer, 1

Server

51,9312 3 High CPU

usage,

moderate

memory

Many Clients,

4 Fuzzers, 1

Server

121,466 6 Very high

CPU, high

memory

The results of EdgeFuzz, based on the aforemen-

tioned scenarios (Figures 5, 6, and 7) are presented

in Table 3, which outlines a comparative examina-

tion of fuzzing use cases, including various setups of

clients, fuzzer, and a server. The results are based on

the Tool 1. In the simplest use-case with one client,

one fuzzer, and one server, we notice high proﬁ-

ciency with the fastest response time

50ms, no request

drops, and low resource utilization, making it ideal for

controlled testing conditions. As the complexity ad-

vances with numerous clients and a single fuzzer, we

observe a degradation in efﬁciency, shown by a slower

response time of

200 ms and a higher request drop

rate of 4.31%, proposing that a single Fuzzer may turn

into a bottleneck under weighty client load. The use-

case with numerous clients and Fuzzers shows im-

proved handling of higher request volumes, handling

the most requests with a drop rate of 2.78%, and iden-

tifying the most vulnerabilities, yet this scenario in-

cludes increased resource utilization and presents dif-

ﬁculties in managing concurrency effectively. This

scenario is reasonable for stress-testing the server’s

ability to deal with synchronous inputs and for recog-

nizing possible crashes under load.

To demonstrate the effectiveness of EdgeFuzz in

detecting vulnerabilities, we successfully replicated

some CVEs based on ApacheTomcat, Apache Struts,

and Jetty, as shown in Table 4. However, these vulner-

abilities have already been patched. We selected these

platforms because they use TCP protocol and HTTP

requests.

Table 4: CVEs Identiﬁed By EdgeFuzz.

Platform CVE ID Speciﬁc

Trigger

Short

Description

Apache

Tomcat

CVE-2016-

4917

Use of

backslash in

URLs

Vulnerability

arises from

how Tomcat

handles URLs

with reverse or

slashes

allowing

bypassing of

security

checks

Apache Struts CVE-2018-

11776

Namespace

manipulation

or additional

forward

slashes in

URLs

Alteration of

expected

routing based

on additional

slashes

Jetty CVE-2015-

2080

Use of special

characters in

escaped URL

paths

Improper

handling of

specially

crafted URL

paths that

include

encoded

characters

6 CONCLUSIONS

We have developed a new distributed systems black-

box Fuzzer named EdgeFuzz, which operates as a

middleware node between the client and server nodes.

It intercepts client requests, mutates them in real time,

and forwards them to the server. EdgeFuzz noti-

ﬁes the user if a crash has occurred and provides a

log of the identiﬁed vulnerability. We compared the

effectiveness of EdgeFuzz with other Fuzzers such

as AFLNET, BOOFUZZ, and Peach, and found that

EdgeFuzz outperforms them in terms of the speed of

identifying bugs. We also tested TCP protocol-based

applications that can emulate distributed system envi-

ronments. EdgeFuzz is lightweight and can be set up

in different scenarios, such as making four nodes of

EdgeFuzz, which is not possible with other Fuzzers.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

624

Currently, EdgeFuzz is implemented in commodity

hardware. In the future, we have a plan to imple-

ment EdgeFuzz in Mellanox ConnectX-6, Blueﬁed-

2 SmartNIC, and Barefoot Toﬁno 2. We also want

to evaluate other protocol behaviors with different

speciﬁcations to handle the requests to extend Edge-

Fuzz towards a complete testing suite for network-

ing/distributed computing environments.

REFERENCES

Anderson, R. (2020). Security engineering: a guide to

building dependable distributed systems. John Wiley

& Sons.

Ba, J., B

ohme, M., Mirzamomen, Z., and Roychoudhury,

A. (2022). s. In 31st USENIX Security Symposium

(USENIX Security 22), pages 3255–3272.

Biswas, S., Sohel, M., Sajal, M. M., Afrin, T., Bhuiyan, T.,

and Hassan, M. M. (2018). A study on remote code

execution vulnerability in web applications. In Inter-

national conference on cyber security and computer

science (ICONCS 2018), pages 50–57.

Borrello, P., Fioraldi, A., D’Elia, D. C., Balzarotti, D.,

Querzoni, L., Giuffrida, C., et al. (2024). Predictive

context-sensitive fuzzing. In Network and Distributed

System Security (NDSS) Symposium.

Caballero, J., Yin, H., Liang, Z., and Song, D. (2007). Poly-

glot: Automatic extraction of protocol message format

using dynamic binary analysis. In Proceedings of the

14th ACM conference on Computer and communica-

tions security, pages 317–329.

De Ruiter, J. and Poll, E. (2015). Protocol state fuzzing

of {TLS} implementations. In 24th USENIX Security

Symposium (USENIX Security 15), pages 193–206.

Durumeric, Z., Li, F., Kasten, J., Amann, J., Beekman, J.,

Payer, M., Weaver, N., Adrian, D., Paxson, V., Bai-

ley, M., et al. (2014). The matter of heartbleed. In

Proceedings of the 2014 conference on internet mea-

surement conference, pages 475–488.

Fan, R. and Chang, Y. (2018). Machine learning for black-

box fuzzing of network protocols. In Information and

Communications Security: 19th International Con-

ference, ICICS 2017, Beijing, China, December 6-8,

2017, Proceedings 19, pages 621–632. Springer.

Gao, J., Bai, X., and Tsai, W.-T. (2011). Cloud testing-

issues, challenges, needs and practice. Software Engi-

neering: An International Journal, 1(1):9–23.

Gascon, H., Wressnegger, C., Yamaguchi, F., Arp, D., and

Rieck, K. (2015). Pulsar: Stateful black-box fuzzing

of proprietary network protocols. In Security and Pri-

vacy in Communication Networks: 11th EAI Inter-

national Conference, SecureComm 2015, Dallas, TX,

USA, October 26-29, 2015, Proceedings 11, pages

330–347. Springer.

Ge, X., Yang, F., and Han, Q.-L. (2017). Distributed net-

worked control systems: A brief overview. Informa-

tion Sciences, 380:117–131.

Jiang, S., Zhang, Y., Li, J., Yu, H., Luo, L., and Sun,

G. (2024). A survey of network protocol fuzzing:

Model, techniques and directions. arXiv preprint

arXiv:2402.17394.

Juan, V., Huang, L., and Hinz, S. (2020). Pulpy. [Online].

Available: GitHub repository.

Liang, Y., Liu, S., and Hu, H. (2022). Detecting logical

bugs of {DBMS} with coverage-based guidance. In

31st USENIX Security Symposium (USENIX Security

22), pages 4309–4326.

Man

es, V. J., Han, H., Han, C., Cha, S. K., Egele, M.,

Schwartz, E. J., and Woo, M. (2019). The art, science,

and engineering of fuzzing: A survey. IEEE Transac-

tions on Software Engineering, 47(11):2312–2331.

Munea, T. L., Lim, H., and Shon, T. (2016). Network proto-

col fuzz testing for information systems and applica-

tions: a survey and taxonomy. Multimedia tools and

applications, 75:14745–14757.

Pham, V.-T., B

ohme, M., and Roychoudhury, A. (2020).

Aﬂnet: a greybox fuzzer for network protocols. In

2020 IEEE 13th International Conference on Software

Testing, Validation and Veriﬁcation (ICST), pages

460–465. IEEE.

Pham, V.-T., B

ohme, M., Santosa, A. E., C

aciulescu,

A. R., and Roychoudhury, A. (2019). Smart greybox

fuzzing. IEEE Transactions on Software Engineering,

47(9):1980–1997.

Srivastava, P. and Payer, M. (2021). Gramatron: Effective

grammar-aware fuzzing. In Proceedings of the 30th

acm sigsoft international symposium on software test-

ing and analysis, pages 244–256.

STEEN, M. and TANENBAUM, A. (2017). Distributed

systems.[sl]: Maarten van steen leiden. The Nether-

lands, pages 206–210.

T., C. (2020). DistWalk. [Online]. Available: GitHub repos-

itory.

Takanen, A., Demott, J. D., Miller, C., and Kettunen, A.

(2018). Fuzzing for software security testing and qual-

ity assurance. Artech House.

Thorpe, L. (2021). Packet courier. [Online]. Available:

GitHub repository.

Tsankov, P., Dashti, M. T., and Basin, D. (2012). Sec-

fuzz: Fuzz-testing security protocols. In 2012 7th In-

ternational Workshop on Automation of Software Test

(AST), pages 1–7. IEEE.

Yao, D., Zhang, J., Harris, I. G., and Carlsson, M. (2024).

Fuzzllm: A novel and universal fuzzing framework

for proactively discovering jailbreak vulnerabilities in

large language models. In ICASSP 2024-2024 IEEE

International Conference on Acoustics, Speech and

Signal Processing (ICASSP), pages 4485–4489. IEEE.

Zhang, Z., Zhang, H., Zhao, J., and Yin, Y. (2023). A sur-

vey on the development of network protocol fuzzing

techniques. Electronics, 12(13):2904.

Zhao, X., Qu, H., Xu, J., Li, X., Lv, W., and Wang, G.-G.

(2024). A systematic review of fuzzing. Soft Comput-

ing, 28(6):5493–5522.

EdgeFuzz: A Middleware-Based Security Testing Tool for Vulnerability Discovery in Distributed Computing Applications

625