Is publishing CRLs over HTTP a potential vulnerability?

There is no such thing as a non-signed CRL; the signature field is mandatory, and any system that uses the CRL will verify the signature.

In pure X.509, a CRL will be deemed "acceptable" as a source of information about the revocation status of a given certificate E if it is signed by an "allowed revocation issuer": the CRL's signature must match the public key contained in an already validated certificate, whose subjectDN is equal to the issuerDN of E (you can have a distinct DN if E contains the relevant CRL distribution point extension and the CRL has a matching Issuer distribution point extension; but let's forget this additional complexity). Complete rules are exposed in section 6.3. Note that "pure X.509" is supposed to work in the context of the Directory, the kind-of worldwide LDAP server that references everything under unambiguous Distinguished Names.

Since the Directory does not really work, because it does not, as it were, exist at all, existing implementations tend to implement stricter and simpler rules. Generally speaking, a Web browser validating a certificate E issue by CA C will accept a CRL only if it is also signed by the same CA, with the same key. This rule keeps path validation simple and bounded (otherwise, you may imagine a situation where you must get a CRL for each certificate in the path, and each CRL is to be verified against another CRL issuer certificate that requires its own path validation, and so on). Therefore, producing your own CRL relatively to your own root CA is unlikely to have any actual effect.

CRL, like certificates, are thus objects which are always signed, and never used without verifying that signature(*), so they can be served over plain HTTP. Using HTTPS to serve CRL is just wasted resources; it may even prevent CRL download from working since some implementations (e.g. Windows) refuse to follow HTTPS URL when validating certificates (be it for CRL, OCSP, or extra intermediate CA download), because that would mean SSL, then another certificate to validate, and possibly an endless loop.

^{(*) I here exclude root CA "certificates", traditionally self-signed; these are not real certificates in the X.509 sense, but only objects that mimic the encoding rules of certificates.}

About the replay attack, the CRL is time stamped with the date of generation and a date for the next update. The nextUpdate date is mandatory in the PKIX profile. If a certificate is revoked, the old CRL can be replayed before nextUpdate if an unsecure channel is used.