I've had a very quick look at the rplay source and found:

* In rplay/rplay.c line 600, the use of atoi() on something that
  looks like unsanitized data from a remote server:

        remote_size = -1;
        p = rptp_parse(response, "size");
        if (p)
            remote_size = atoi(p);

* Various malloc() without a check of failure, such as:

contrib/rplaytool-1.1/misc.c:    INFO *info = (INFO *) malloc (sizeof (INFO));
contrib/rplaytool-1.1/misc.c-
contrib/rplaytool-1.1/misc.c-    info->filename[0] = '\0';

contrib/rplaytool-1.1/rplaytool_stubs.c:                sp = (SPOOL *) malloc (sizeof (SPOOL));
contrib/rplaytool-1.1/rplaytool_stubs.c-                sp->id = id;

contrib/xjukebox-0.9/xjukebox.c-  if (*list != NULL)
contrib/xjukebox-0.9/xjukebox.c-    *list = (spool_info **)realloc(*list, (*items_count + 1) *
--
contrib/xjukebox-0.9/xjukebox.c:      *list = (spool_info **)malloc(sizeof(spool_info *));
contrib/xjukebox-0.9/xjukebox.c-    }
contrib/xjukebox-0.9/xjukebox.c-  (*list)[*items_count] = new_item;
contrib/xjukebox-0.9/xjukebox.c-  if ((*nlist != NULL)  && (*nlist != empty_list))
contrib/xjukebox-0.9/xjukebox.c-    *nlist = (String *)realloc(*nlist, (*items_count + 1) * sizeof(String));
contrib/xjukebox-0.9/xjukebox.c-  else
contrib/xjukebox-0.9/xjukebox.c:    *nlist = (String *)malloc(sizeof(String));
contrib/xjukebox-0.9/xjukebox.c-  (*nlist)[*items_count] = new_item->sound;

contrib/xjukebox-0.9/xjukebox.c:  new_item = (spool_info *)malloc(sizeof(spool_info));
contrib/xjukebox-0.9/xjukebox.c-
contrib/xjukebox-0.9/xjukebox.c-  new_item->sid = atoi (1 + rptp_parse (new_info, "id"));

librplay/async.c:               new->data = malloc(nbytes);
librplay/async.c-               memcpy(new->data, ptr, nbytes);

librplay/async.c:       new = (ibuf *) malloc(sizeof(ibuf));
librplay/async.c-       new->next = NULL;

librplay/rplay.c:           rp->data = (char *) malloc(rp->data_size);
librplay/rplay.c-           memcpy(rp->data, packet, rp->data_size);

rplay/rplay.c:          name = (char *) malloc(strlen(cwd) + strlen(argv[optind]) + 2);
rplay/rplay.c-          strcpy(name, cwd);

rplayd/rplayd.c:            s = (SERVER *) malloc(sizeof(SERVER));
rplayd/rplayd.c-            s->next = NULL;

rx/rxanal.c:            *subexps = (struct rexp_node **)malloc (sizeof (struct rexp_node *) * *re_nsub);
rx/rxanal.c-          else
rx/rxanal.c-            *subexps = (struct rexp_node **)realloc (*subexps,
rx/rxanal.c-                                                     sizeof (struct rexp_node *) * *re_nsub);
rx/rxanal.c-        }
rx/rxanal.c-    }
rx/rxanal.c-      if (node->params.pair.left)
rx/rxanal.c-    id = rx_posix_analyze_rexp (subexps, re_nsub, node->params.pair.left, id);

rx/rxnfa.c:     consed = (struct rx_se_list *) malloc (sizeof (*consed));
rx/rxnfa.c-     *consed = template;

rx/rxnode.c:  n = (struct rexp_node *) malloc (sizeof (*n));
rx/rxnode.c-  rx_bzero ((char *)n, sizeof (*n));

rx/rxunfa.c:      cr = (struct rx_cached_rexp *)malloc (sizeof (*cr));
rx/rxunfa.c-      rx_bzero ((char *)cr, sizeof (*cr));

Has the code been audited?

Hi Vicent,

thanks a lot for trying to improve the security of Debian.
Do you mind sharing the CVEs for the security issues you mentioned?

Thanks!
  Thorsten

No CVEs (yet), but I posted the issue to the oss-security list
a couple of days ago:

https://www.openwall.com/lists/oss-security/2025/10/17/3

Hi.  I see two RC bugs open against rplay.  I don't really know
anything about rplay.  One of my packages, vtwm, has some integration
on it, so I am being threatened with autoremoval due to these bugs.

Do you intend to fix them?  It doesn't look entirely straightforward
to maintain rplay since it is a network daemon written in C.  Such
programs typically have many vulnerabilities.

If I don't hear, I will drop support for rplay in vtwm.

Ian.

Hi Ian,

yes, I will fix both. At the moment I am looking at the security RC bug.
Unfortunately it looks like this is only possible with an API change.
Anyway, I try to upload a fixed version by end of next week.

    Thorsten

close 1118224 3.3.2-22
thanks

As per:

 rplay (3.3.2-22) unstable; urgency=medium
 .
   * CVE-2025-62672
     fix SIGSEGV with crafted packets in rplay_unpack()
     (Closes: #118224)
     Unfortunately this issue can not be fixed in rplay_unpack(), so this
     function has been deprecated and a new function rplay_unpack_n() has
     been introduced.  The old function rplay_unpack() now always returns
     an error.  According to codesearch.d.n, rplay_unpack() is only used
     in rplay itself but not in any reverse dependency, so no other
     package should be affected by this change.
   * rplay-server: add systemd unit file (Closes: #1039352)

(there was a typo in the bug closer).